Skip to content
FR

Identification, Authentication, and Identity Federation

Step 25 of 38

CISSP IAM: Identification, MFA, Passkeys, and Identity Federation

Introduction

CISSP identity and access management connects identity proofing, authentication factors, session controls, and trusted federation. This lesson covers tasks 5.1, 5.2, and 5.3 of Domain 5, Identity and Access Management (IAM) (13% of the exam, ISC2 exam outline effective 15 April 2024): control physical and logical access to assets, manage identification and authentication of people, devices, and services, and federate identity with a third-party service. The next lesson covers authorization mechanisms, the provisioning lifecycle, and authentication systems (tasks 5.4-5.6).

IAM is the control plane of modern security: nearly every attack path ends with someone obtaining or abusing an identity. For the exam, you must distinguish identification (claiming an identity), authentication (proving it), authorization (what it may do), and accountability (tracing actions back to it), and choose the right authentication and federation design for a scenario.

Learning objectives

After this lesson you can:

  1. Explain physical and logical access control to information, systems, devices, facilities, applications, and services.
  2. Distinguish identification, authentication, authorization, and accountability; AAA conventionally means authentication, authorization, and accounting.
  3. Compare authentication factors, biometrics error rates, and MFA and passwordless options.
  4. Design identity registration, proofing, and credential management, including vaults and SSO.
  5. Manage sessions securely, including timeouts and re-authentication.
  6. Explain federation concepts: identity provider (IdP), service provider (SP), trust, and assertions, across on-premises, cloud, and hybrid environments.
  7. Authenticate people, devices, and services, and use groups, roles, and just-in-time (JIT) access appropriately.

1. Controlling access to assets

1.1 Subjects, objects, and the access control process

A subject (user, process, device) requests access to an object (file, database, door, API). Access control involves four steps:

  1. Identification: the subject claims an identity (username, badge number, device ID).
  2. Authentication: the subject proves the claim.
  3. Authorization: the system decides what the authenticated identity may do.
  4. Accountability (auditing): protected logs associate actions with identities and support investigation; logging alone does not make repudiation impossible.

Nonrepudiation needs strong authentication, unique identities, tamper-resistant logs, and often digital signatures.

1.2 Physical and logical access

Domain Asset examples Typical controls
Physical Facilities, server rooms, devices, media Badges, locks, biometrics, mantraps, guards, visitor logs, cable locks
Logical Systems, applications, data, services, APIs Passwords, MFA, ACLs, roles, encryption, network access control

Combine them: a badge reader that checks both the physical door and the user's logical account status (a terminated employee's badge is disabled with the account). Converged physical and logical access also helps detect impossible situations, such as inconsistent access locations. A VPN login while physically present is not by itself impossible or proof of compromise.

1.3 Control types

Access controls can be preventive, detective, corrective, deterrent, compensating, and directive, and implemented as administrative, technical, or physical controls. The exam often asks which type a specific control represents (for example, an access log review is detective and administrative).

1.4 Core principles

  • Least privilege: the minimum rights needed for the job.
  • Need to know: access to information only if required for duties.
  • Separation of duties: no single person completes a critical process alone.
  • Default deny: access is refused unless explicitly granted.
  • Zero trust: never trust by network location; verify explicitly, use least privilege, assume breach.

2. Identification and authentication

2.1 Identity types

Identities exist for people (employees, contractors, customers), devices (laptops, phones, IoT, servers), and services/workloads (applications, scripts, containers, APIs). Non-human identities often outnumber human ones and are frequently overlooked: shared service accounts with never-expiring passwords are a classic finding.

Each identity needs a unique identifier so that accountability is possible. Shared or generic accounts defeat accountability and should be avoided or tightly controlled (vaulted, checked out, and logged).

2.2 Authentication factors

Factor Category Examples Weaknesses
Something you know Knowledge Password, PIN, security questions Guessable, phishable, reused
Something you have Possession Smart card, hardware token, authenticator app, FIDO2 key, phone Can be lost or stolen; SMS can be intercepted or SIM-swapped
Something you are Inherence Fingerprint, iris, face Cannot be changed if compromised; error rates; privacy concerns
Somewhere you are Location Geolocation, IP range Spoofable; best as a contextual signal
Something you do Behavior Typing rhythm, gait Probabilistic; supports risk-based decisions

Multi-factor authentication (MFA) uses two or more different factor categories, generally knowledge, possession, and inherence. Location and behavior can inform risk but are not standalone NIST authenticator categories. A password plus a PIN is not MFA (both knowledge). A password plus an authenticator app is. Not all second factors are equal: phishing-resistant methods (FIDO2/WebAuthn security keys, smart cards with PKI) beat one-time codes, which beat SMS codes. MFA fatigue attacks (push bombing) are countered by number matching, rate limiting, and phishing-resistant factors.

2.3 Passwords and passwordless

Current guidance (NIST SP 800-63B-4, final in 2025) favors length over complexity rules, screening against breached and common passwords, no mandatory periodic rotation without evidence of compromise, support for password managers (paste allowed), and rate limiting or lockout to resist online guessing. For systems following this NIST profile, require at least 15 characters for a password used alone, or at least eight when it is used only within MFA. Store passwords with a slow, salted hash (Argon2, bcrypt, scrypt, PBKDF2) to resist offline cracking; salting defeats rainbow tables and makes identical passwords hash differently, and peppering adds a secret stored separately.

Passwordless authentication replaces passwords with cryptographic credentials: FIDO2/WebAuthn passkeys use a private key held on the device (or synced securely) and a public key at the service. WebAuthn verifies the relying-party context and origin, resisting look-alike-site credential relay. A stolen authenticated session or compromised endpoint remains a separate threat. User verification and authenticator properties determine assurance; not every passwordless method is MFA, and synced passkeys do not meet AAL3's non-exportable-key requirement. Recovery must meet the applicable assurance requirements through a documented, risk-appropriate process; a weak recovery path can undermine strong primary authentication.

2.4 Biometrics

Biometric systems enroll a template and compare later samples.

Metric Meaning Effect of tightening the threshold
FRR / Type I error False rejection of authorized users Increases
FAR / Type II error False acceptance of unauthorized users Decreases
CER / EER Crossover error rate, where FRR equals FAR Lower CER means a more accurate system

For high-security environments, set the threshold to minimize false acceptance, accepting more false rejections. Consider liveness detection to resist spoofing with photos or molds, protect templates (encrypted, ideally stored on the device), and address privacy and accessibility. Compare CER only under comparable datasets and test conditions. Also assess presentation attacks, demographic performance, accessibility, and the intended operating threshold. Under NIST's network-authentication profile, biometrics activate a physical authenticator rather than act alone; face recognition requires presentation-attack detection, and voice biometric comparison is not allowed.

2.5 Tokens and one-time passwords

  • HOTP (counter-based, RFC 4226) and TOTP (time-based, RFC 6238) generate one-time codes. Printed one-time look-up secrets are possession authenticators under NIST guidance, not automatically a second knowledge secret merely because the user reads and types them.
  • Hardware tokens and smart cards hold keys in tamper-resistant chips.
  • Out-of-band verification (call or message to a known device) adds a channel but SMS is weak.

2.6 Common attacks on authentication

Attack Description Defense
Brute force / dictionary Guessing many passwords Rate limiting, lockout or throttling, long passphrases, MFA
Password spraying One common password across many accounts Detect low-and-slow patterns, MFA, banned password lists
Credential stuffing Reuse of breached credentials MFA, breach screening, bot protection
Phishing / adversary-in-the-middle Capturing credentials or session tokens Phishing-resistant MFA (FIDO2), user training, conditional access
Keylogging / malware Capturing input EDR, hardware keys, virtual keyboards are weak
Pass-the-hash / ticket abuse Reusing credential material Credential Guard, tiered administration, short ticket lifetimes
Session hijacking / token theft Stealing a session cookie or token TLS, protected cookies, short lifetimes, and supported sender-constrained token mechanisms where applicable
SIM swapping Taking over a phone number Avoid SMS for high-value accounts
Social engineering of help desk Convincing support to reset credentials Strong identity verification for resets

3. Identity registration, proofing, and credential management

3.1 Registration and proofing

Choose the required identity assurance from the service risk; not every low-risk account needs legal-identity proofing. Identity proofing resolves a claimed real-world identity, validates evidence and attributes, and verifies the applicant's association with them. SP 800-63A-4 defines IAL1–3: IAL1 and IAL2 permit specified remote or on-site processes, while IAL3 requires on-site attended proofing and biometric collection. Identity assurance (IAL), authenticator assurance (AAL), and federation assurance (FAL) are distinct. Registration records the identity in the directory and binds it to authenticators. Proofing establishes confidence in the real-world identity; later authentication establishes control of the bound authenticator. Strong performance in one does not automatically establish the other.

3.2 Establishing the identity

  • Source of truth: HR system for employees, a vendor-management system for contractors, a customer registration flow for customers.
  • Unique identifiers that are never reused for another person.
  • Attribute accuracy and privacy: collect only what is needed.

3.3 Credential management

  • Issue credentials securely (never by email in clear text) and require change or enrollment at first use.
  • Credential vaults and privileged access management (PAM): store secrets, rotate them automatically, check out privileged credentials with approval and session recording, and eliminate hard-coded secrets in code and scripts through secrets managers.
  • Password managers reduce reuse for users.
  • Revoke or disable credentials promptly at termination or role change; recover through a verified process.

3.4 Single sign-on (SSO)

SSO lets a user authenticate once and access multiple applications without re-entering credentials. Benefits: fewer passwords, central policy and MFA enforcement, faster deprovisioning, better logs. Risks: the SSO identity provider becomes a single point of failure and a high-value target; compromise can affect relying applications within the configured trust and authorization scope. An outage may block new authentication while existing sessions remain valid under their own policy. Mitigate with strong MFA, high availability, monitoring, and conditional access. SSO does not remove the need for per-application authorization.

3.5 Just-in-time (JIT) access

JIT grants privileges only when needed and for a limited time, often through request and approval workflows. It reduces standing privilege and the window of abuse. JIT can also refer to just-in-time provisioning of accounts in an application at first federated login.

4. Session management

After authentication, the system maintains a session. Poor session handling undoes strong authentication.

  • Generate unpredictable session identifiers, transmit only over TLS, mark cookies Secure, HttpOnly, and SameSite.
  • Apply idle and absolute timeouts appropriate to risk. Require reauthentication for sensitive actions and use step-up when a higher authentication assurance is needed; these are related but distinct decisions.
  • Invalidate server-side sessions and refresh credentials on logout or relevant compromise events according to policy. A self-contained access token may remain usable until expiry unless revocation is enforced; bind supported tokens to a key rather than assuming arbitrary device fingerprinting stops replay.
  • Detect concurrent or impossible sessions.
  • Treat token lifetime as a tradeoff: short-lived access tokens with refresh tokens limit theft impact.
  • Screen lock and secure kiosk timeouts protect physical endpoints.
  • Rotate the session identifier after login and privilege changes to resist fixation. Secure, HttpOnly, and SameSite cookies address specific threats; they do not make a bearer cookie safe once stolen.

5. Federated identity

5.1 Concepts

Federation lets an organization accept identities asserted by another organization or system under an established trust. The identity provider (IdP) authenticates users and issues assertions or tokens. The service provider (SP) or relying party consumes them and makes authorization decisions. The user can avoid separate passwords, while the relying party still needs account association and authorization state, possibly provisioned just in time.

Term Meaning
IdP Authenticates the user and vouches for them
SP / relying party Provides the service and trusts the IdP
Assertion / token Signed statement about the user (identity, attributes, authentication time)
Trust relationship Agreement and cryptographic setup (metadata, certificates) between IdP and SP
Claims / attributes Data in the assertion, such as email, groups, or roles

5.2 Standards in brief

The next lesson goes deeper into SAML, OAuth, and OIDC; for now, remember their role.

  • SAML 2.0: XML-based assertions, commonly used for enterprise web SSO and B2B federation.
  • OpenID Connect (OIDC): identity layer on OAuth 2.0, using JSON Web Tokens (JWT) and typically used for modern web and mobile apps.
  • OAuth 2.0: an authorization framework for delegated access to APIs, not an authentication protocol by itself.

5.3 Federation models

  • Cross-organization (B2B) federation: partner users sign in with their home IdP. The SP must decide which attributes it trusts and enforce authorization locally.
  • Social/customer identity (CIAM): customers sign in with consumer identity providers or an organization-managed customer directory.
  • Workforce federation across on-premises, cloud, and hybrid: an on-premises directory (such as Active Directory) synchronizes or federates with a cloud IdP; applications in any location trust the same IdP. Design for resilience: if the on-premises directory is offline, can cloud applications still authenticate? Maintain monitored emergency access independent of the failed dependency, with protected phishing-resistant authenticators and tested recovery. Follow platform-specific guidance for exceptions to blocking policies; an exception is not permission for an unprotected account.
  • Federation hubs and brokers: simplify multi-partner trust.

5.4 Security considerations

  • Validate assertions: use a maintained protocol library to check trusted signatures, issuer, audience, recipient, time limits, and transaction binding. Apply the protocol's nonce, response-correlation, and replay-cache rules as required; unique IDs and timestamps alone do not stop reuse.
  • Trust is transitive risk: a weak partner IdP weakens your applications. Require MFA at the IdP or enforce step-up at the SP through authentication context claims.
  • Attribute release: minimize attributes shared (privacy).
  • Account linking and deprovisioning: bind identities using an issuer-scoped stable subject identifier; an email address alone is not a safe automatic account-linking key. When an employee leaves a partner, you may not know; use short session lifetimes, SCIM or periodic reviews, and contractual notification.
  • Protect signing keys and certificates: rotate before expiry; stolen signing keys allow forged assertions (the "Golden SAML" attack).

6. Authenticating people, devices, and services

Subject Typical methods Notes
People Passwords with MFA, FIDO2, smart cards, biometrics, federation Use risk-based (adaptive) policies
Devices Machine certificates (EAP-TLS), TPM-backed keys, device compliance posture, MAC authentication (weak) Proves control of a device credential; health and management status require separate posture evidence
Services / workloads Mutual TLS, short-lived tokens, workload identities from the cloud platform, API keys with scope limits, secrets manager Avoid long-lived static keys; rotate automatically

6.1 Groups, roles, and AAA

  • Groups collect users with similar access needs; roles collect permissions for a job function.
  • AAA services (RADIUS, TACACS+, Diameter) provide authentication, authorization, and accounting centrally for network access.
  • Assign permissions to groups or roles rather than individuals to simplify review and removal.

6.2 Risk-based and adaptive authentication

Policies consider user, device health, location, behavior, and resource sensitivity. A login from a new country on an unmanaged device to the finance application triggers step-up or denial; a login from the usual laptop at the usual time does not. Combine with continuous evaluation so sessions are revoked when risk changes.

7. Worked example: choosing an authentication design

Scenario. Meridian Health Group runs a patient portal for 200,000 patients, a clinician portal for 3,000 staff, and a payroll application for HR. Assume an existing clinical smart-card system can be configured within the rollout budget. The audit found: clinicians reuse passwords and share badges at shared workstations; patients are locked out frequently and call the help desk, where agents reset access after asking for the date of birth; HR logins use passwords only. Budget allows hardware keys for HR and a mobile authenticator for others.

Step 1: Classify risk per population.

  • HR/payroll: high impact, small population, managed devices.
  • Clinicians: high impact, shared workstations, speed matters in care situations.
  • Patients: large population, mixed device quality, usability and accessibility matter.

Step 2: Select authenticators.

  • HR: FIDO2 security keys (phishing-resistant), SSO with conditional access, privileged HR roles via JIT.
  • Clinicians: cryptographic smart-card authentication activated by a PIN at shared workstations (possession plus knowledge), fast user switching, SSO to clinical applications, short idle timeouts and automatic lock.
  • Patients: password plus app-based MFA or passkeys, with prompts and step-up governed by the required assurance; avoid SMS where an alternative exists.

Step 3: Fix recovery. Help desk resets must verify identity beyond the date of birth: a documented recovery process using bound authenticators, recovery codes, or appropriate reproofing, with subscriber notification and additional controls for high-risk accounts. A callback or manager approval alone is not a universal high-assurance recovery method.

Step 4: Session and monitoring. Idle timeouts, step-up before viewing sensitive records or changing bank details, and alerts for impossible travel and mass lookups.

Why not the alternatives? Forcing frequent password rotation would encourage predictable variations and does not address reuse. Adding more security questions gives attackers more guessable data. SMS codes for everyone are better than nothing but vulnerable to SIM swapping and phishing. A single enterprise MFA method for all groups ignores the shared workstation constraint, which will push clinicians to workarounds.

8. Mini case study

Scenario. Cobalt Insurance uses a cloud SSO platform for 90 SaaS apps. A phishing email captured an employee's password and a one-time code, and the attacker replayed the session cookie to read claims data for three hours. Other findings: (a) a shared service account "svc-batch" with a password in a script is used by five scripts; (b) a partner broker network federates into the claims portal, with no check of the partner's MFA; (c) session lifetime is 30 days; (d) the break-glass admin account has no monitoring.

Task. Recommend corrective actions.

Commented solution.

  1. Phishing-resistant MFA (FIDO2/passkeys) for employees, starting with administrators and claims staff. This resists the look-alike-site credential and OTP relay path through origin binding. It does not invalidate a session cookie already stolen through another route; revoke compromised sessions and investigate endpoint compromise.
  2. Session controls: shorten session and token lifetimes, require re-authentication for sensitive actions, bind tokens to devices where supported, and revoke sessions on risk events.
  3. Service account (a): move to a secrets manager with automatic rotation, give each script its own workload identity with least privilege, and remove the hard-coded password.
  4. Federation (b): require the partner IdP to assert strong authentication (authentication context) or enforce step-up at Cobalt; limit released attributes and roles; review the partner contract for deprovisioning notices.
  5. Break-glass (d): preserve independent recovery, protect the authenticator, alert on any use, and test it regularly. For Microsoft Entra, current guidance calls for separate cloud-only emergency accounts and phishing-resistant authentication.
  6. Detection: add impossible-travel and anomalous-token alerts and log all authentication events to the SIEM.

Order: the compromise path (phishing-resistant MFA, session control) comes first; then privileged non-human credentials; then federation hygiene and break-glass governance.

9. Common pitfalls and exam tips

  • Pitfall: calling two knowledge factors "MFA". Different categories are required.
  • Exam tip: the best answer for phishing resistance is FIDO2/WebAuthn or PKI smart cards, not SMS or app codes.
  • Exam tip: biometrics: lowering FAR raises FRR. High-security sites favor low FAR; compare CER only under matched conditions, alongside operational and presentation-attack performance.
  • Pitfall: treating SSO as a replacement for authorization or MFA.
  • Exam tip: identification is a claim, authentication is proof; accountability needs unique IDs and protected logs.
  • Pitfall: ignoring recovery and help desk paths; they are common attack routes.
  • Exam tip: OAuth is about authorization (delegated access); OIDC adds authentication; SAML is for enterprise assertions.
  • Pitfall: shared accounts. If unavoidable, vault them, require checkout, and record sessions.
  • Exam tip: federation answers usually include validating signatures, enforcing MFA at the IdP, minimizing attributes, and a defined deprovisioning process.
  • Exam tip: "reduce standing privilege" points to JIT access and PAM.

Key terms

  • Identification / authentication / authorization / accountability: claim, proof, permission, traceability.
  • MFA: two or more factor categories.
  • FIDO2 / WebAuthn / passkey: public-key, origin-bound phishing-resistant authentication.
  • FAR / FRR / CER: biometric false acceptance, false rejection, and crossover error rates.
  • Identity proofing: verifying real-world identity before credential issuance.
  • PAM / vault: controlled storage, rotation, and checkout of privileged secrets.
  • SSO: one authentication event for many applications.
  • JIT access: privileges granted when needed for a limited time.
  • IdP / SP: identity provider / service provider (relying party).
  • Assertion / claim: signed statement and its attributes.

Summary checklist

  • I can separate identification, authentication, authorization, and accountability.
  • I can pick authentication factors and explain why MFA needs different categories.
  • I can compare phishing-resistant methods with OTP and SMS.
  • I can explain biometric error rates and the crossover error rate.
  • I can describe identity proofing, credential vaults, SSO, and JIT access.
  • I can design session management with timeouts and step-up authentication.
  • I can describe IdP, SP, assertions, and security checks in federation.
  • I can choose authentication for people, devices, and services.

Pair logical identities with physical access and facility security. Continue with authorization and identity provisioning to control permissions throughout their lifecycle, and apply secure design and zero-trust principles to each access decision.

Official sources