Questions? Call 1.800.716.8955

Chapter 18

Identity and Access Management

Exam objective 4.5: Given a scenario, apply concepts related to identity and access management. This objective covers the full lifecycle of digital identities and the controls that decide what those identities can do. It includes provisioning and deprovisioning accounts, assigning permissions and understanding their implications, identity proofing, federation, and single sign-on with SAML, LDAP, and OAuth (plus OpenID Connect, which builds on OAuth). It also covers account types (user, privileged, service, third-party, and emergency access), multifactor authentication methods, access control models, access management policies, access reviews, and modern password concepts including passkeys, password managers, passwordless authentication, and password best practices.

This is a "given a scenario" objective, which means you must apply the concepts, not just define them. Expect questions that describe an organization's problem—a terminated employee who still has VPN access, a partner that needs access to a web portal without new accounts, administrators who share a domain admin password, users who reuse passwords—and ask you to choose the best control. Several identity scenarios also appear as performance-based questions, such as matching authentication methods to factors or selecting the right access control model for a situation. This is one of the largest objectives on the exam, so this chapter is correspondingly long.

Identity and Access Management Fundamentals

Identity and access management (IAM) is the set of processes and technologies that ensure the right identities have the right access to the right resources at the right time, and nothing more. IAM builds directly on the AAA concepts from Chapter 1: an identity is claimed (identification), proven (authentication), granted permissions (authorization), and tracked (accounting).

An identity is the digital representation of a subject—a person, device, application, or service—usually stored in a directory with attributes such as name, department, job title, manager, and group memberships. An account is the means by which an identity accesses a particular system. One person may have one identity but several accounts: a standard user account, a separate administrative account, and accounts in SaaS applications linked by federation.

IAM matters because identity has become the primary security perimeter. Users work from home, applications live in the cloud, and attackers increasingly log in rather than break in—using phished, stolen, or guessed credentials. Most of the controls in this chapter exist to make credentials harder to steal, less useful when stolen, and easier to revoke.

The Identity Lifecycle

Provisioning

Provisioning is creating an account and granting the access an identity needs. In a well-run organization, provisioning is triggered by an authoritative source—typically the HR system for employees or a vendor management process for contractors—rather than by an informal email to the help desk. This is often described as the joiner-mover-leaver (JML) process:

  • Joiner — a new hire's record in HR triggers account creation, mailbox setup, and assignment of baseline access based on job role.
  • Mover — a transfer or promotion triggers adding new access and, just as importantly, removing access the old role required.
  • Leaver — a termination or departure triggers disabling and eventually deleting accounts. Good provisioning practices include approval workflows (the manager and, for sensitive systems, the data owner approve access), role-based templates so that new users receive a consistent baseline, documentation of who approved what, and automation. Automated provisioning, often driven by SCIM (System for Cross-domain Identity Management), pushes account creation and changes from the identity provider to SaaS applications so that accounts are created consistently and quickly. Chapter 19 discusses user provisioning as an automation use case.

Deprovisioning

Deprovisioning is removing access when it is no longer needed: when an employee leaves, a contractor's engagement ends, or a role changes. Deprovisioning failures are among the most common IAM weaknesses. Orphaned accounts—accounts belonging to people who have left—remain usable by the former employee, by anyone who knows the password, or by an attacker who discovers them. Effective deprovisioning includes:

  • Timeliness — accounts are disabled at or before the moment of separation. For involuntary terminations, access is often disabled while the employee is in the termination meeting.
  • Completeness — every account is addressed, including SaaS applications, VPN, cloud consoles, shared mailboxes, and accounts not tied to the central directory.
  • Session and token revocation — disabling a password does not necessarily end existing sessions. OAuth refresh tokens, persistent cookies, and mobile app sessions may remain valid until revoked.
  • Disable, then delete — disabling first preserves the account's data and audit history for a retention period (and for legal holds) before deletion.
  • Asset recovery — laptops, badges, and hardware tokens are collected (Chapter 15).
  • Credential rotation — any shared or service credentials the person knew are changed. A marketing manager resigns and leaves on Friday. HR updates the HR system, which disables her directory account through automated provisioning. Two weeks later, the security team discovers she has continued logging in to the company's social media management platform, which was purchased by the marketing department and uses its own local accounts rather than SSO. The fix is twofold: bring the application under SSO and SCIM so deprovisioning is automatic, and perform a periodic account audit to find applications that sit outside the central identity system.

Common trap

Disabling an account and revoking access are not always the same. If a scenario says a terminated user's account was disabled but the user still accessed email from a phone, the problem is an active session or refresh token that was not revoked. The fix is to revoke sessions and tokens as part of deprovisioning.

Permission Assignments and Implications

How permissions are assigned determines how manageable and secure access becomes over time.

  • Direct assignment gives permissions to individual user accounts. It is simple for a single case but becomes unmanageable at scale, and it is hard to audit: to know who can access a folder, you must inspect every entry.
  • Group-based assignment gives permissions to groups and puts users in groups. Adding or removing a user from a group changes access consistently. This is the foundation of role-based access control.
  • Inheritance lets permissions flow from a parent object (a folder, an organizational unit, a cloud resource group) to its children. Inheritance simplifies administration but can grant access unexpectedly when an object is moved or created under a broadly permissioned parent.
  • Explicit deny generally overrides allow in systems such as NTFS and AWS IAM, which can be used to carve exceptions but also creates confusing troubleshooting.

The implications of permission assignment include:

  • Privilege creep — users accumulate permissions as they change roles because new access is added but old access is not removed.
  • Excessive permissions — granting broad access ("Everyone: Full Control," wildcard cloud policies like "Action": "*") because it is easier than determining the minimum, violating least privilege.
  • Toxic combinations — individually reasonable permissions that together violate separation of duties, such as the ability to create vendors and approve payments.
  • Effective permissions — the actual access a user has after combining direct, group, inherited, and denied permissions, which can differ greatly from what an administrator expects.
  • Blast radius — the more an account can do, the more damage occurs when it is compromised. An attacker who phishes a user with broad access gains broad access.

Exam tip

When a scenario describes a user who still has access from a previous job, the issue is privilege creep and the fix is an access review (recertification) combined with a mover process that removes old access. When it describes permissions that are too broad from the start, the principle being violated is least privilege.

Identity Proofing

Identity proofing is verifying that a person is who they claim to be before issuing credentials. Authentication proves that the person logging in is the same one who enrolled; identity proofing ensures that the person who enrolled was the real person in the first place. If proofing is weak, an attacker can enroll as someone else and every later authentication will faithfully confirm the wrong person.

NIST SP 800-63A describes identity proofing in three steps:

  • 1. Resolution — collect enough attributes (name, date of birth, address) to distinguish the person uniquely.
  • 2. Validation — confirm that the evidence (a passport, driver's license, or other document) is genuine, current, and accurate, for example by checking security features or querying the issuing source.
  • 3. Verification — confirm that the person presenting the evidence is its rightful owner, for example by comparing a live selfie with the document photo (with liveness detection) or by an in-person check.

NIST defines identity assurance levels (IAL): IAL1 requires no real proofing (self-asserted), IAL2 requires remote or in-person proofing with strong evidence, and IAL3 requires in-person or supervised remote proofing with the strongest evidence.

Identity proofing appears in many forms: an HR department checking a new hire's documents before creating an account, a bank's onboarding that scans a driver's license and selfie, and—critically—help desk password resets and MFA re-enrollment. Attackers frequently call help desks impersonating employees to get an MFA device reset. Strong proofing for these requests (callback to a known number, manager verification, video verification against the HR photo) is essential. Knowledge-based authentication (KBA)—questions such as "What was your first car?"—is weak for both proofing and recovery, because answers are guessable, researchable on social media, or exposed in breaches. Federation and Single Sign-On

Federation

Federation is a trust relationship between separate organizations or security domains that allows identities from one domain to access resources in another without separate accounts. The domain that authenticates the user is the identity provider (IdP); the domain that hosts the resource and trusts the IdP's assertions is the service provider (SP), or relying party (RP) in OAuth and OpenID Connect terminology.

In a federation, the IdP authenticates the user and sends the SP a signed statement—an assertion or token—containing the user's identity and attributes (also called claims), such as email address, department, or group membership. The SP never sees the user's password. The SP uses the attributes to make authorization decisions.

Federation is everywhere: an employee signs in to dozens of SaaS applications using the company's IdP (such as Microsoft Entra ID, Okta, or Ping Identity); a university's students access research databases through a federation of institutions; a consumer signs in to a website with an existing social account. Benefits include fewer passwords for users, centralized authentication policies such as MFA and conditional access enforced in one place, and—critically—centralized deprovisioning: disabling the account at the IdP cuts off access to every federated application. The trade-off is concentration of risk: if the IdP or its signing keys are compromised, every application that trusts it is exposed. Single Sign-On (SSO)

Single sign-on (SSO) lets a user authenticate once and then access multiple applications without re-entering credentials. SSO and federation overlap: federation is the trust relationship that often makes SSO possible across organizational boundaries, while SSO describes the user experience. Within a single organization, SSO is commonly built on Kerberos (for on-premises Windows resources) and SAML or OpenID Connect (for web and cloud applications).

SSO improves security as well as convenience. Users with one strong credential and MFA are less likely to write passwords down or reuse them, and security teams can enforce policy and monitor authentication in one place. The risk is that a single compromised SSO session or credential opens many doors, which is why SSO is almost always paired with MFA and session controls.

The objective names three SSO technologies—SAML, LDAP, and OAuth—and you should also know OpenID Connect.

Saml

The Security Assertion Markup Language (SAML), currently version 2.0, is an XML-based open standard for exchanging authentication and authorization data between an IdP and an SP. SAML is the dominant protocol for enterprise web SSO to SaaS applications.

SAML has three roles: the principal (the user, working through a browser), the identity provider, and the service provider. The SAML assertion is an XML document, digitally signed by the IdP, containing an authentication statement (who the user is and how and when they authenticated), attribute statements, and conditions such as the intended audience and a validity window.

The most common flow, SP-initiated SSO, works like this:

  • 1. The user browses to the service provider (for example, a payroll SaaS application).
  • 2. The SP does not have a session for the user, so it generates a SAML AuthnRequest and redirects the browser to the IdP.
  • 3. The IdP authenticates the user—password plus MFA, or recognizes an existing IdP session.
  • 4. The IdP builds a signed SAML assertion and returns it to the browser in an HTML form that automatically posts it to the SP's Assertion Consumer Service (ACS) URL.
  • 5. The SP validates the assertion: checks the signature against the IdP's certificate, confirms the audience is itself, verifies the time window, and checks that the assertion has not been used before.
  • 6. The SP creates a local session and grants access based on the identity and attributes. In IdP-initiated SSO, the user starts at the IdP's portal and clicks an application tile; the IdP sends an unsolicited assertion to the SP. This is convenient but more susceptible to certain replay and injection attacks because the SP did not request it.

Notice that the browser carries the assertion, but the IdP and SP never need to talk directly during login. The trust is established in advance by exchanging metadata: entity IDs, endpoint URLs, and the IdP's signing certificate.

Figure 18.1: In SP-initiated SAML SSO, the browser carries the AuthnRequest to the IdP and the signed assertion back to the SP

<saml:Assertion ID="_a75adf55" IssueInstant="2026-10-04T14:02:11Z" Version="2.0">

 <saml:Issuer>https://idp.example.com</saml:Issuer>
 <ds:Signature>...</ds:Signature>
 <saml:Subject><saml:NameID>jlee@example.com</saml:NameID></saml:Subject>

<saml:Conditions NotBefore="2026-10-04T14:02:11Z" NotOnOrAfter="2026-10-

04T14:07:11Z">
 <saml:AudienceRestriction><saml:Audience>https://payroll.saas.com</
saml:Audience></saml:AudienceRestriction>
 </saml:Conditions>
 <saml:AttributeStatement>

<saml:Attribute

Name="department"><saml:AttributeValue>Finance</saml:AttributeValue></saml:Attribute>
 </saml:AttributeStatement>
</saml:Assertion>

Security considerations include protecting the IdP's signing keys (an attacker with the key can forge assertions for any user—the "Golden SAML" technique), validating signatures correctly (XML signature wrapping attacks exploit sloppy validation), short assertion lifetimes, and audience restrictions.

OAuth 2.0

OAuth 2.0 is an authorization framework (RFC 6749) that lets a user grant an application limited access to their resources on another service without sharing their password. When an application asks, "Allow this app to read your calendar?", it is using OAuth. OAuth uses JSON and HTTP rather than XML, which makes it well suited to mobile apps, single-page web applications, and APIs.

OAuth defines four roles:

  • Resource owner — the user who owns the data.
  • Client — the application requesting access.
  • Authorization server — issues tokens after authenticating the user and obtaining consent.
  • Resource server — the API that holds the data and accepts tokens.

The key artifacts are the access token, a short-lived credential the client presents to the resource server; scopes, which limit what the token permits (such as calendar.read); and the refresh token, a longer-lived credential the client uses to obtain new access tokens without bothering the user. The recommended flow for most applications is the authorization code flow with PKCE (Proof Key for Code Exchange):

  • 1. The client generates a random secret (code verifier) and sends its hash (code challenge) along with the requested scopes when redirecting the user's browser to the authorization server.
  • 2. The user authenticates at the authorization server and approves the requested scopes on a consent screen.
  • 3. The authorization server redirects the browser back to the client with a short-lived authorization code.
  • 4. The client exchanges the code, plus the original code verifier, for an access token (and optionally a refresh token) through a direct back-channel request to the authorization server.
  • 5. The client calls the resource server's API, presenting the access token.

Figure 18.2: The OAuth 2.0 authorization code flow with PKCE redeems the code over a direct back channel using the code verifier

PKCE ensures that an attacker who intercepts the authorization code cannot redeem it without the code verifier. Other grant types exist: the client credentials grant for machine-to-machine access with no user involved, and the device authorization grant for devices with limited input such as smart TVs. Older flows such as the implicit grant and the resource owner password grant are deprecated in current best practice.

Common trap

OAuth by itself is authorization, not authentication. An access token says "the bearer may read this calendar," not "this is Jane." Applications that treat a raw OAuth access token as proof of identity can be tricked. When a scenario needs authentication or identity information on top of OAuth, the answer is OpenID Connect.

OAuth risks include consent phishing, in which attackers register malicious applications and trick users into granting broad scopes (such as reading all email), and theft of tokens, which—as bearer tokens— work for whoever holds them. Defenses include restricting which applications users may consent to, reviewing granted permissions, short token lifetimes, and revoking tokens during incident response and deprovisioning.

OpenID Connect (OIDC)

OpenID Connect (OIDC) is an identity layer built on top of OAuth 2.0 that adds authentication. A client requests the openid scope, and in addition to an access token, the authorization server (now called the OpenID provider) returns an ID token: a JSON Web Token (JWT) that is signed by the provider and contains claims about the user and the authentication event—the issuer (iss), the subject identifier (sub), the intended audience (aud), expiration (exp), and often name and email. OIDC also defines a UserInfo endpoint for retrieving additional profile claims.

A JWT has three Base64URL-encoded parts separated by dots—header, payload, and signature: eyJhbGciOiJSUzI1NiJ9.eyJpc3MiOiJodHRwczovL2lkcC5leGFtcGxlLmNvbSIsInN1YiI6IjI0NDgiLCJhdW QiOiJhcHAxMjMiLCJleHAiOjE3OTE2NDgwMDB9.Sg4...

Decoded payload:

{ "iss": "https://idp.example.com", "sub": "2448", "aud": "app123", "exp": 1791648000 } OIDC is the modern choice for consumer sign-in ("Sign in with Google/Apple/Microsoft"), mobile applications, and many new enterprise applications. Note that JWT payloads are encoded, not encrypted, so they should not carry secrets; and relying parties must validate the signature, issuer, audience, and expiration of every ID token.

Ldap

The Lightweight Directory Access Protocol (LDAP) is an open protocol for querying and modifying directory services—hierarchical databases of users, groups, computers, and other objects. Microsoft Active Directory, OpenLDAP, and many other directories support LDAP. LDAP is not itself a web SSO protocol, but it is listed under SSO because it provides the centralized directory that authentication systems check credentials and group memberships against: many applications, VPNs, and network devices authenticate users by binding to the corporate directory over LDAP, so one directory account works across them.

Directory objects are identified by a distinguished name (DN) made of components such as common name (CN), organizational unit (OU), and domain component (DC):

CN=Jordan Lee,OU=Finance,OU=Staff,DC=example,DC=com

Clients authenticate to the directory with a bind operation. An anonymous bind requires no credentials and should be disabled for anything beyond the most limited read access; a simple bind sends a DN and password; a SASL bind supports stronger mechanisms such as Kerberos.

  • LDAP's security depends on transport protection:
  • Option Port Protection
  • LDAP TCP 389 None by default; simple bind sends passwords in cleartext

LDAP with StartTLS TCP 389 Upgrades the session to TLS after connecting LDAPS TCP 636 TLS from the start of the connection

Global catalog (AD) TCP 3268 / 3269 (TLS)

Forest-wide searches in Active Directory

Applications that build LDAP queries from user input can be vulnerable to LDAP injection, analogous to SQL injection, so input must be validated and escaped.

Note

Kerberos (TCP/UDP 88) is the default authentication protocol in Active Directory and provides on-premises SSO: a user authenticates once to the key distribution center and receives a ticket-granting ticket (TGT), then requests service tickets for each resource without re-entering a password. Active Directory uses Kerberos for authentication and LDAP for directory lookups; the two work together.

Comparing SSO and Federation Protocols

Feature SAML 2.0 OAuth 2.0 OpenID Connect LDAP

Primary purpose

Authentication and attribute exchange (web SSO)

Delegated authorization Authentication on top of OAuth

Directory query and credential check

Data format

XML assertions JSON; access tokens (often JWT)

JSON; ID token is a JWT Binary protocol (ASN.1)

Typical use Enterprise SSO to SaaS

API access, app permissions

Consumer and mobile sign-in, modern SSO

Internal apps and devices

authenticating to a directory

Key artifact

Signed assertion Access and refresh tokens, scopes

ID token Bind with DN and password

Exam clue "XML," "assertion," "IdP and SP," "enterprise web SSO"

"Allow app to access your data," "scopes," "consent," "API"

"Sign in with...," "ID token," "identity on top

of OAuth"

"Directory," "port 389/636," "DN," "bind"

Memory aid

SAML says who you are with XML. OAuth says what an app may do for you. OIDC says who you are using OAuth's plumbing. LDAP looks you up in the directory. If the question mentions XML, think SAML. If it mentions a user granting an application access to data without sharing a password, think OAuth.

Account Types

Different kinds of accounts carry different risks and need different controls.

User Accounts

User accounts are standard accounts assigned to individual people for day-to-day work. They should have no administrative privileges, follow least privilege, be uniquely tied to one person (so actions are attributable), and be protected by MFA. Shared accounts—one login used by multiple people—destroy accountability because no one can tell who performed an action; they should be eliminated or tightly controlled through a privileged access management (PAM) tool that checks out credentials to named individuals and records who used them.

Privileged Accounts

Privileged accounts have elevated rights to configure systems, change security settings, access sensitive data, or manage other accounts. The objective distinguishes two scopes:

  • Global privileged accounts have authority across the entire environment—Active Directory Domain Admins and Enterprise Admins, a cloud tenant's Global Administrator, or the AWS root user. Compromise of one of these typically means compromise of everything.
  • Local privileged accounts have authority over a single system—the local Administrator account on a Windows workstation or root on one Linux server. They are less powerful individually but dangerous in aggregate: if every workstation's local administrator shares the same password, compromising one machine yields the password for all of them, enabling lateral movement. Microsoft's Local Administrator Password Solution (LAPS) addresses this by setting a unique, randomly generated, regularly rotated password on each machine and storing it in the directory. Best practices for privileged accounts include:
  • Separate accounts — administrators use a standard account for email and browsing and a separate privileged account only for administration.
  • Privileged access management (PAM) — a vault stores privileged credentials, checks them out for a limited time, rotates them after use, and records sessions.
  • Just-in-time (JIT) elevation — privileges are granted only when needed and expire automatically (see Access Control Models later in this chapter).
  • Phishing-resistant MFA for all privileged access.
  • Privileged access workstations (PAWs) — hardened devices used only for administration.
  • Minimal membership — as few global administrators as possible, reviewed frequently, with alerts whenever membership changes.

Service Accounts

Service accounts are non-human accounts used by applications, services, and scheduled tasks to authenticate to other systems—for example, a web application's account for connecting to its database, or a backup agent's account. Service accounts are risky because they often hold broad privileges, use passwords that never change, are not tied to a person who will notice misuse, and are sometimes allowed interactive logon when they do not need it. Attackers target them through techniques such as Kerberoasting, which cracks the passwords of service accounts offline.

Controls include:

  • Grant the minimum privileges needed and deny interactive logon.
  • Use managed identities where possible: group managed service accounts (gMSAs) in Active Directory and cloud managed identities automatically rotate long, complex credentials that no human knows.
  • Store any static secrets in a secrets manager or vault rather than in code or configuration files.
  • Assign a human owner to every service account and include them in access reviews.
  • Monitor for unusual use, such as a service account logging on interactively.

Third-Party Accounts

Third-party accounts are accounts for vendors, contractors, partners, auditors, and managed service providers. Third parties often need access to support systems they sold or to deliver services, and attackers know that third parties are a path in—many major breaches started with a vendor's credentials. Controls include sponsorship by an internal employee, contractually defined access (Chapter 24), expiration dates on accounts, restriction to specific systems and times, MFA, session monitoring or recording, and federation with the partner's IdP where possible so the partner's own deprovisioning applies. Vendor remote access should go through a controlled path such as a PAM gateway rather than a standing VPN account.

Emergency Access Accounts

Emergency access accounts, often called break-glass accounts, are highly privileged accounts reserved for situations in which normal administrative access is unavailable—for example, when the federation service or MFA provider is down, or when a misconfigured conditional access policy has locked out every administrator. They are designed to be used rarely and noticed every time.

Best practices include:

  • Keep a small number (commonly two) of cloud-only accounts that do not depend on the federated IdP or on-premises directory.
  • Use very long, randomly generated credentials or FIDO2 security keys, stored securely—for example, split between two sealed envelopes in separate safes, or held in a vault requiring dual control.
  • Exclude them from policies that could lock them out, but compensate with heavy monitoring.
  • Alert immediately on any sign-in, and require documentation and review of every use.
  • Test them periodically and rotate credentials after use.

Real-world scenario

A cloud administrator deploys a conditional access policy that requires a compliant device for all administrators, but forgets that the administrators' devices are not yet enrolled. Every administrator is locked out of the tenant. The organization recovers by retrieving a break-glass account's credentials from the safe—an account excluded from that policy—signs in, corrects the policy, and then rotates the break-glass credentials. The security team receives an automatic alert when the account is used and documents the event.

Account type

Main risk Key controls

User Phishing, password reuse, privilege creep

Least privilege, MFA, unique accounts, access reviews

Privileged (global)

Full environment compromise Minimal membership, PAM vault, JIT, phishing-resistant MFA, PAWs

Privileged (local)

Lateral movement via shared local admin passwords

LAPS, remove unnecessary local admin rights

Service Static passwords, excess rights, Kerberoasting

gMSA or managed identity, secrets vault, no interactive logon, owner assigned

Third-party Vendor compromise used as entry point

Sponsorship, expiration, restricted scope, MFA, session monitoring

Emergency access

Abuse of an unmonitored all-powerful account

Secure storage, dual control, alert on every use, periodic testing

Multifactor Authentication

Multifactor authentication (MFA) requires two or more different authentication factors—something you know, something you have, something you are, and optionally somewhere you are and something you do (Chapter 1). MFA dramatically reduces account takeover because a stolen password alone is no longer enough. The objective lists five MFA methods.

Hard Tokens

A hard token (hardware token) is a physical device that proves possession. Examples include key fobs that display a changing one-time code, smart cards containing a private key and certificate (such as the US government's PIV and CAC cards), and USB or NFC security keys such as FIDO2 keys. Hard tokens are strong because the secret lives in tamper-resistant hardware and cannot be copied by malware on a computer. Their drawbacks are cost, logistics (shipping, replacing lost tokens), and the possibility that users leave them plugged in or attached to their laptop bag.

Soft Tokens

A soft token is software that performs the same function as a hardware token, typically an authenticator app on a smartphone (Microsoft Authenticator, Google Authenticator, Duo, and others) that generates one-time codes or receives push notifications. Soft tokens are inexpensive and convenient, since nearly everyone carries a phone, but they inherit the phone's risks: malware, device theft, and loss.

Push notifications ("Approve sign-in?") are convenient but vulnerable to MFA fatigue (push bombing), in which an attacker who has the password triggers repeated prompts until the user approves one to make them stop. Number matching—requiring the user to type a number shown on the login screen into the app—and showing the sign-in location in the prompt make push far more resistant to this attack.

One-Time Passwords (OTP)

A one-time password (OTP) is a code valid for a single use. Two algorithms dominate:

  • HOTP (HMAC-based One-Time Password, RFC 4226) — computes codes from a shared secret and a counter that increments each time a code is generated. A code remains valid until used, which is a weakness if it is intercepted.
  • TOTP (Time-based One-Time Password, RFC 6238) — computes codes from a shared secret and the current time, typically producing a new six-digit code every 30 seconds. Most authenticator apps use TOTP.

OTP codes can also be delivered by SMS, voice call, or email. These delivery methods are weaker: SMS can be intercepted through SIM swapping, SS7 network attacks, or malware, and email is only as secure as the mailbox. NIST classifies SMS and voice OTP as a "restricted" authenticator, meaning organizations that use it must assess the risk and offer alternatives. All OTP methods—even TOTP from an app—are vulnerable to real-time phishing, in which an adversary-in-the-middle proxy relays the code to the real site within its validity window.

HOTP uses a counter (think How many times); TOTP uses Time. TOTP codes expire in about 30 seconds; HOTP codes do not expire until used.

Biometrics

Biometrics authenticate users by physical characteristics (fingerprint, face, iris, retina, palm veins, voice) or behavioral characteristics (typing rhythm, gait, signature dynamics). Biometric systems are measured by their error rates:

  • False acceptance rate (FAR) — the rate at which an impostor is incorrectly accepted (a type II error). This is the security failure.
  • False rejection rate (FRR) — the rate at which a legitimate user is incorrectly rejected (a type I error). This is the usability failure.
  • Crossover error rate (CER) or equal error rate — the point at which FAR and FRR are equal when sensitivity is adjusted. A lower CER indicates a more accurate system and is used to compare systems.

Raising sensitivity lowers FAR but raises FRR, and vice versa. High-security environments tolerate more false rejections to keep false acceptances low.

Biometric concerns include privacy (biometric data is sensitive personal data under many laws), the impossibility of changing a fingerprint if a template is stolen, and spoofing with photos, masks, or molded fingerprints, which is countered by liveness detection. In modern devices, biometrics are often used locally to unlock a cryptographic key on the device (as with passkeys) rather than being sent to a server—this design keeps the biometric template on the device.

Backup Codes

Backup codes (recovery codes) are a set of single-use codes generated when a user enrolls in MFA, intended for use when the primary factor is unavailable—a lost phone or forgotten security key. Each code works once. They solve a real problem: without a recovery method, users locked out of MFA call the help desk, and help desk resets are a favored target of social engineers. Backup codes must be stored securely (in a password manager or printed and kept safe, not in a file named "codes.txt" on the desktop), and their use should generate an alert and prompt the user to re-establish their primary factor.

MFA method Factor Strengths Weaknesses Phishing-resistant?

Hard token (FIDO2 security key, smart card)

Have Secret in tamper-resistant hardware; origin-bound with FIDO2

Cost, distribution, loss Yes (FIDO2 and smart card/PKI)

MFA method Factor Strengths Weaknesses Phishing-resistant?

Hard token (OTP fob)

Have No phone required Code can be phished and relayed

No

Soft token (authenticator app,

TOTP or push)

Have Low cost, convenient Phone loss, malware, MFA fatigue, real-time phishing

No (unless app uses device-bound passkeys)

SMS/voice/email

Otp

Have (phone or mailbox)

Easy to deploy, no app needed

SIM swapping, interception, phishing

No

Biometrics Are Nothing to remember or carry

Privacy, cannot be changed, spoofing, FAR/FRR trade-off

Depends on implementation (strong when used to unlock a local key)

Backup codes Know or have (a stored secret)

Account recovery without help desk

Can be stolen if stored carelessly

No

Exam tip

When a scenario asks for the most phishing-resistant MFA, pick FIDO2/WebAuthn security keys or passkeys, or certificate-based smart cards. When it describes users approving prompts they did not initiate, the attack is MFA fatigue and the fix is number matching or phishing-resistant MFA. When it describes an attacker taking over a victim's phone number, the attack is SIM swapping and the fix is moving away from SMS.

Access Control Models

An access control model defines how authorization decisions are made. The objective lists six; attribute-based access control (ABAC), which Chapter 1 mentions, often appears as a related concept. Discretionary Access Control (DAC)

In discretionary access control (DAC), the owner of a resource decides who can access it. When you create a file on a Windows NTFS volume or a document in a cloud drive and share it with colleagues, you are exercising DAC. DAC is flexible and familiar, but it depends on every owner making good decisions; a user can share sensitive data inappropriately, and malware running as the user inherits the user's discretion. DAC is implemented through access control lists (ACLs) attached to each object. Mandatory Access Control (MAC)

In mandatory access control (MAC), a central authority assigns security labels (classifications such as Confidential, Secret, and Top Secret) to objects and clearances to subjects, and the system enforces access based on comparing them. Users—even owners—cannot change labels or grant access at their discretion. MAC often adds compartments or categories to enforce need to know: a Top Secret clearance does not grant access to a Top Secret compartment the user is not read into. MAC is used in military and government systems and appears in hardened operating systems through SELinux and similar frameworks. It is the most restrictive and least flexible model.

Role-Based Access Control (RBAC)

In role-based access control (RBAC), permissions are assigned to roles that correspond to job functions (Accounts Payable Clerk, Help Desk Tier 1, Database Administrator), and users are assigned to roles. When someone changes jobs, an administrator changes their role rather than editing dozens of individual permissions. RBAC is the most common model in enterprises and cloud platforms because it scales well, supports least privilege when roles are designed carefully, and simplifies access reviews. Its weakness is role explosion—creating so many narrowly defined roles that the model becomes as complex as direct assignment.

Rule-Based Access Control

In rule-based access control, access is determined by rules set by an administrator that apply to everyone, regardless of identity or role. Firewall rules and router ACLs are the classic example: "deny all traffic from 203.0.113.0/24" applies to every packet that matches. Other examples include "block uploads larger than 100 MB" or "allow access only from the corporate IP range." Rule-based access control is often combined with other models—RBAC decides who has access, and rules add global conditions.

Common trap

Both role-based and rule-based access control abbreviate to RBAC. Read the question carefully. If access depends on a user's job function, it is role-based. If it depends on administrator-defined conditions that apply to all subjects, such as a firewall ACL or a global restriction, it is rule-based.

Time-Based Access Control

Time-based access control restricts access to defined time windows—for example, payroll staff can log on only between 7:00 a.m. and 7:00 p.m. on weekdays, or a contractor's account works only during the contract's business hours. Time-of-day restrictions reduce the window in which stolen credentials can be used and make after-hours activity an obvious anomaly. Time-based restrictions can be implemented as logon hours in Active Directory, as conditions in cloud access policies, or as account expiration dates.

Just-in-Time (JIT) Access

Just-in-time (JIT) access grants privileges only at the moment they are needed, for a limited duration, and then revokes them automatically. Instead of an administrator being a permanent member of Domain Admins (standing privilege), they request elevation for a specific task, an approver or policy grants it for, say, two hours, and the membership expires. Tools such as Microsoft Entra Privileged Identity Management, PAM vaults, and cloud JIT VM access implement this pattern, often with approval workflows, justification, MFA at activation, and session recording.

JIT reduces the attack surface dramatically: an attacker who compromises the administrator's account at 3 a.m. finds an account with no standing privileges. JIT is the operational expression of the least privilege and Zero Trust principles from Chapter 1.

Attribute-Based Access Control (ABAC)

Attribute-based access control (ABAC) makes decisions by evaluating attributes of the subject (department, clearance, employment type), the object (classification, owner), the action, and the environment (time, location, device compliance) against policy. ABAC is the most granular and flexible model—"allow physicians in the cardiology department to read records of patients in cardiology, from a managed device, during their shift"—and underpins modern conditional access and Zero Trust policy engines.

  • Model Who or what decides Example Exam clue
  • Discretiona
  • ry (DAC)

Resource owner User shares a folder with colleagues "Owner," "share," ACLs set by users Mandatory

(MAC)

Central authority via labels and clearances

Secret document readable only by Secret-cleared users

"Labels," "classification," "clearance," most restrictive

Role-based Job role Help desk role can reset passwords "Job function," "role," "group" Rule-based Administrator-defined global rules

Firewall ACL; uploads over 100 MB blocked

"Rules apply to all," ACLs on network

devices

Time-basedTime windows Logons allowed only 7 a.m.-7 p.m. weekdays

"Business hours," "logon hours"

Just-in-timeRequest, approval, and automatic expiry

Two-hour elevation to admin for a change window

"No standing privileges," "temporary

elevation"

Attribute-based (ABAC)

Policy evaluating many attributes

Access only from managed device in home country

"Attributes," "context," "conditional access"

Access Management

Authentication

Within access management, authentication refers to the organization's choice and enforcement of how users prove identity for each kind of access. A mature authentication strategy is risk-based: low-risk access may need only SSO with MFA from a managed device, while privileged access requires phishing-resistant MFA from a privileged access workstation. Conditional access or adaptive authentication evaluates signals at sign-in—user, device compliance, location, IP reputation, and behavior—and decides whether to allow access, require step-up MFA, limit the session, or block. Impossible travel detection, for example, flags a login from London 30 minutes after one from Toronto.

Authentication management also covers session controls (session lifetimes, reauthentication for sensitive actions, idle timeouts), account lockout or throttling after repeated failed attempts, and the logging of authentication events for monitoring (Chapter 17).

Policies

Access management is governed by policies of two kinds:

  • Logical/technical policies are rules enforced by systems. Examples include Group Policy settings that enforce password length and lockout thresholds, conditional access policies requiring MFA, cloud IAM policies granting specific actions on specific resources, firewall ACLs, and session timeouts. They operate automatically and consistently.
  • Administrative/business policies are written organizational rules that define who should get access and how. Examples include an access control policy requiring manager approval for access requests, an account management policy requiring quarterly reviews of privileged access, an acceptable use policy, and a rule that contractors' accounts expire at the end of their contracts. People carry them out, and technical policies often implement them.

The two work together: the business policy says "all remote access requires MFA"; the technical policy in the VPN and IdP enforces it.

# Example cloud IAM technical policy (AWS-style JSON): read-only access to one bucket, # only from the corporate network

  • {
  • "Effect": "Allow",
  • "Action": ["s3:GetObject", "s3:ListBucket"],

"Resource": ["arn:aws:s3:::finance-reports", "arn:aws:s3:::finance-reports/*"], "Condition": { "IpAddress": { "aws:SourceIp": "198.51.100.0/24" } }

}

Access Review

An access review (also called access recertification or attestation) is a periodic process in which managers, data owners, or application owners confirm that each user's access is still appropriate, and revoke what is not. Reviews catch privilege creep, missed deprovisioning, toxic combinations, and inappropriate grants. They are required by many regulations and audit frameworks (for example, SOX for access to financial systems).

Effective access reviews:

  • Are scheduled by risk—quarterly for privileged and financial-system access, annually for general access—and also triggered by events such as role changes.
  • Are performed by people who understand whether the access is needed (the user's manager or the resource owner), not merely by IT.
  • Present reviewers with understandable information (role names and descriptions rather than cryptic group names).
  • Result in action: access that is not recertified is removed, and the removal is verified.
  • Avoid "rubber stamping," in which reviewers approve everything to finish quickly. Highlighting unused access and high-risk entitlements helps reviewers focus.

Real-world scenario

During a SOX audit, auditors find that 40 users in the accounts payable system have the ability to approve payments, though only six are in roles that should. The company implements quarterly access reviews in which the AP manager must recertify each user's entitlements, configures the identity governance tool to flag users who hold both "create vendor" and "approve payment" permissions, and removes access that the manager does not recertify within 14 days.

Password Concepts

Passwords remain the most common authenticator and the most commonly abused. The objective covers modern alternatives—passkeys, password managers, and passwordless—and the best practices that make remaining passwords as strong as possible.

Password Best Practices and NIST SP 800-63B

Password guidance has changed significantly over the past decade, and the exam reflects current thinking. The authoritative reference is NIST SP 800-63B, the authentication volume of NIST's Digital Identity Guidelines. Revision 4, finalized in 2025, strengthened guidance that NIST had been moving toward since 2017. The core idea is that traditional rules—forced complexity and frequent expiration— produced predictable, weak passwords (Summer2026! becomes Fall2026!) while frustrating users. Length, screening against known-compromised passwords, and MFA matter far more.

The objective lists specific best practices:

  • Length — Length is the single most important factor in resisting guessing and cracking. NIST SP 800-63B Rev. 4 requires a minimum of 15 characters when a password is the only authentication factor and allows a minimum of 8 when the password is used as part of MFA. Verifiers should permit passwords of at least 64 characters so that users can choose long passphrases, and should accept spaces and all printable characters, including Unicode. A passphrase such as copper kettle marching north quietly is both long and memorable.
  • Complexity — Traditional complexity rules require mixes of uppercase, lowercase, digits, and symbols. NIST now says verifiers should not impose composition rules, because users satisfy them in predictable ways (capital first letter, 1! at the end). Many organizations and compliance frameworks still require complexity, and you may see it in exam scenarios as part of a password policy, but understand that length provides more real strength.
  • Reuse — Users who reuse a password across sites are exposed whenever any of those sites is breached, because attackers use credential stuffing: testing leaked username-password pairs against other services. Policies should prohibit reuse across systems and prevent reuse of recent passwords through password history (for example, remembering the last 24). Password managers make unique passwords for every site practical.
  • Expiration — Expiration (maximum password age) forces users to change passwords after a set period, such as 90 days. NIST now says verifiers should not require periodic changes, but must force a change when there is evidence of compromise. Frequent forced changes lead to incremental, guessable patterns. Some regulations still require periodic expiration, so organizations balance compliance obligations with this guidance.
  • Age — Minimum password age prevents users from changing their password repeatedly in quick succession to cycle through the history list and return to a favorite password. For example, a minimum age of one day combined with a history of 24 makes cycling impractical. (Maximum age is the expiration setting above.)
  • Compromised credential monitoring — Check passwords against lists of passwords known to be compromised, commonly used, or otherwise weak—at creation and change, and continuously as new breach data appears. NIST requires verifiers to compare new passwords against a blocklist of commonly used, expected, or compromised values. Services such as Have I Been Pwned's Pwned Passwords and identity platforms' leaked-credential detection alert or force a reset when a user's credential appears in a breach dump.
  • Account auditing — Regularly review accounts to find problems: dormant or stale accounts, accounts of departed users, accounts with "password never expires," shared accounts, accounts with no MFA registered, and unexpected members of privileged groups. Auditing also reviews authentication logs for failed-attempt patterns.
  • Policy report — Generate reports that show compliance with password and account policy: how many accounts meet length requirements, which accounts are exempt from policy, which have not changed passwords since a known breach, which lack MFA, and which have weak or blank passwords flagged by audit tools. Policy reports give management and auditors evidence that the policy is applied, and identify exceptions to fix.

NIST SP 800-63B also recommends that verifiers:

  • Allow paste into password fields, so users can use password managers.
  • Not use password hints or knowledge-based questions for recovery.
  • Implement rate limiting (throttling) of failed attempts to resist online guessing.
  • Store passwords using a salted, computationally expensive key derivation function (such as PBKDF2, bcrypt, scrypt, or Argon2), never in plaintext or with a fast unsalted hash (Chapter 3).
  • Offer the option to display the password while typing, to reduce typing errors with long passphrases.

Practice Traditional approach Current NIST SP 800-63B guidance

Length Minimum 8 characters Minimum 15 if single-factor (8 if part of MFA); allow at least 64 Complexity Required mix of character types

Do not impose composition rules

Expiration Change every 60-90 days No periodic change; force change on evidence of compromise Blocklist screening Rarely done Required: reject common and compromised passwords Hints and security questions

Common Not allowed

Paste and password managers

Often blocked Allow paste; support password managers

Exam tip

On the exam, when asked for the BEST way to strengthen a password policy, favor length and screening against compromised passwords, combined with MFA. When a question describes users making small predictable changes (Password1, Password2), the culprit is frequent expiration. When it describes users changing passwords several times in a row to get back to an old one, the fix is minimum password age with password history.

Password Managers

A password manager stores credentials in an encrypted vault protected by a master password (and ideally MFA) and generates long, random, unique passwords for each site. Password managers directly address reuse and weakness: users need to remember only one strong master passphrase. Most also autofill credentials only on the matching website domain, which provides some protection against phishing—if the password manager does not offer to fill a login on examp1e.com, that is a warning sign. Enterprise password managers add centralized administration, secure sharing of team credentials, policy enforcement, and reporting on weak or reused passwords. The risks are concentration (the vault is a high-value target, so the master password and MFA must be strong) and vendor compromise—well-designed managers use end-to-end encryption so that the provider cannot read vault contents, and a stolen vault is protected by the strength of the master password and the KDF used to derive the encryption key.

Passwordless Authentication

Passwordless authentication removes the password entirely and replaces it with factors that are harder to steal or phish—typically something you have (a device holding a private key) combined with something you are or know (a biometric or PIN that unlocks it locally). Examples include Windows Hello for Business, FIDO2 security keys, passkeys, certificate-based smart card logon, and authenticator app phone sign-in.

Passwordless eliminates the attacks that target passwords—phishing for passwords, credential stuffing, password spraying, and brute force—and removes the burden of remembering and resetting passwords. Note that magic links sent by email and SMS one-time codes used alone are also marketed as "passwordless," but they are only as strong as the email account or phone number and are not phishing-resistant.

Passkeys, FIDO2, and WebAuthn

A passkey is a FIDO2 discoverable credential: a public-private key pair, unique to one user and one website or application, used in place of a password. Passkeys are the consumer-friendly face of the FIDO standards and are supported by Apple, Google, Microsoft, and major password managers. FIDO2 is the umbrella standard from the FIDO Alliance and the W3C. It consists of two parts:

  • WebAuthn (Web Authentication) — a W3C standard JavaScript API that lets websites (relying parties) ask the browser to create and use public-key credentials.
  • CTAP (Client to Authenticator Protocol) — the FIDO Alliance protocol that lets the browser or operating system communicate with an authenticator, which may be built into the device (a platform authenticator, such as a phone's or laptop's secure enclave or TPM) or external (a roaming authenticator, such as a USB or NFC security key, or a phone used over Bluetooth). Registration works like this:
  • 1. The user, already signed in or creating an account, chooses to create a passkey. The website sends a challenge, its relying party ID (its domain), and user information.
  • 2. The authenticator verifies the user locally (fingerprint, face, or device PIN), generates a new key pair specific to that relying party, and stores the private key securely.
  • 3. The authenticator returns the public key and a credential ID; the website stores the public key with the user's account. No secret is stored on the server.

Authentication works like this:

  • 1. The user visits the site and chooses to sign in with a passkey. The site sends a random challenge.
  • 2. The browser passes the challenge along with the origin (the actual domain the browser is on) to the authenticator.
  • 3. The authenticator verifies the user locally, finds the private key for that relying party ID, and signs the challenge and origin data.
  • 4. The site verifies the signature with the stored public key. If it validates, the user is authenticated.

Figure 18.3: Origin binding lets a passkey sign in to the legitimate site while leaving a lookalike phishing site with nothing to relay

Several properties make passkeys exceptionally strong:

  • Phishing resistance through origin binding. The browser enforces that a credential registered for example.com can only be used on example.com. On a lookalike phishing site, the authenticator has no matching credential, and even an adversary-in-the-middle proxy cannot reuse a signature bound to the wrong origin. The user cannot be tricked into handing over something reusable.
  • Nothing reusable on the server. The server stores only public keys, so a database breach yields nothing an attacker can use to log in.
  • No shared secrets in transit. Each login signs a fresh challenge, so replaying a captured response fails.
  • Built-in MFA. Possession of the device (have) plus local biometric or PIN (are or know) provides two factors in one gesture, and the biometric never leaves the device.

Passkeys come in two forms. Synced passkeys are backed up and synchronized across a user's devices through a cloud account (such as iCloud Keychain, Google Password Manager, or a third-party password manager), which solves the lost-device problem and makes them practical for consumers; their security depends partly on the security of that sync account. Device-bound passkeys never leave a single authenticator, such as a hardware security key, and are preferred for high-assurance and privileged use because the private key cannot be copied.

Memory aid

FIDO2 = WebAuthn + CTAP. WebAuthn is how the website talks to the browser; CTAP is how the browser talks to the authenticator. A passkey is a FIDO2 credential bound to one site's origin, which is why it resists phishing.

Real-world scenario

A financial firm suffers repeated account takeovers despite requiring TOTP codes: attackers use an adversary-in-the-middle phishing kit that relays both the password and the TOTP code to the real site in real time and steals the session cookie. The firm rolls out device-bound FIDO2 security keys for administrators and passkeys for all staff. On the next phishing attempt, users who click the link find that their passkey simply is not offered on the lookalike domain; the phishing kit has nothing to relay.

Chapter Summary

  • The identity lifecycle runs from provisioning (joiner) through role changes (mover) to deprovisioning (leaver). Deprovisioning must be timely and complete, including SaaS accounts and session and token revocation.
  • Permission assignment through groups and roles scales better than direct assignment; watch for privilege creep, excessive permissions, toxic combinations, and inheritance surprises.
  • Identity proofing confirms a person's real-world identity before credentials are issued (resolution, validation, verification); help desk resets need strong proofing too.
  • Federation lets an IdP vouch for users to SPs. SAML uses signed XML assertions for enterprise web SSO; OAuth 2.0 delegates authorization with access tokens and scopes; OIDC adds authentication with a JWT ID token; LDAP (389/636) queries directories that back authentication; Kerberos provides on-premises SSO.
  • Account types: user, privileged (global versus local; use PAM, JIT, LAPS), service (managed identities, vaulted secrets), third-party (sponsorship, expiration, monitoring), and emergency access (break-glass with secure storage and alerting).
  • MFA methods: hard tokens, soft tokens, OTP (HOTP counter, TOTP time), biometrics (FAR, FRR, CER), and backup codes. FIDO2 and smart cards are phishing-resistant; SMS is weakest.
  • Access control models: DAC (owner decides), MAC (labels and clearances), role-based (job function), rule-based (global admin rules), time-based (windows), JIT (temporary elevation), and ABAC (attributes).
  • Access management combines authentication strategy, logical/technical and administrative/business policies, and periodic access reviews.
  • Password best practices emphasize length, blocklist and compromised credential monitoring, no reuse, and no routine expiration per NIST SP 800-63B, plus minimum age, account auditing, and policy reports. Password managers, passwordless methods, and passkeys (FIDO2 = WebAuthn + CTAP) reduce reliance on passwords.

Key Terms

Provisioning; deprovisioning; joiner-mover-leaver; SCIM; orphaned account; privilege creep; toxic combination; effective permissions; identity proofing; identity assurance level (IAL); federation; identity provider (IdP); service provider (SP); relying party; single sign-on (SSO); SAML; assertion; OAuth 2.0; access token; refresh token; scope; PKCE; consent phishing; OpenID Connect (OIDC); ID token; JSON Web Token (JWT); LDAP; LDAPS; distinguished name; bind; Kerberos; privileged account; LAPS; privileged access management (PAM); service account; gMSA; third-party account; emergency access (break-glass) account; hard token; soft token; MFA fatigue; number matching; HOTP; TOTP; SIM swapping; biometrics; FAR; FRR; CER; backup codes; DAC; MAC; role-based access control; rule-based access control; time-based access control; just-in-time (JIT) access; standing privilege; ABAC; conditional access; logical/technical policy; administrative/business policy; access review; NIST SP 800-63B; credential stuffing; password history; minimum password age; compromised credential monitoring; blocklist; account auditing; policy report; password manager; passwordless; passkey; FIDO2; WebAuthn; CTAP; synced passkey; device-bound passkey; origin binding.

Review Questions

  • 1. A company allows employees to sign in to a third-party payroll website using their corporate credentials. The payroll site redirects users to the corporate identity provider, which returns a digitally signed XML document containing the user's identity and department. Which technology is in use?
  • A. LDAP
  • B. OAuth 2.0
  • C. SAML
  • D. Kerberos
  • 2. A mobile fitness application asks users, "Allow FitTrack to read your activity data from HealthCloud?" Users approve without giving FitTrack their HealthCloud password, and FitTrack receives a token limited to reading activity data. Which framework does this describe?
  • A. SAML
  • B. OAuth 2.0
  • C. LDAP
  • D. RADIUS
  • 3. Attackers have repeatedly obtained employees' passwords and then sent dozens of sign-in approval requests until users accepted one. Which of the following would BEST mitigate this attack? (Select TWO.)
  • A. Enable number matching for push notifications
  • B. Increase the password expiration interval
  • C. Deploy FIDO2 passkeys or security keys
  • D. Switch push approvals to SMS one-time passwords
  • E. Disable account lockout
  • 4. An auditor finds that every Windows workstation in the company uses the same local Administrator password, which has not changed in four years. Which solution BEST addresses this finding?
  • A. Add all workstations to the Domain Admins group
  • B. Implement LAPS to set unique, rotated local administrator passwords
  • C. Require complexity for the local Administrator password
  • D. Disable the domain administrator account
  • 5. Two days after an employee was terminated, logs show she accessed corporate email from her personal phone even though her directory account was disabled on her last day. What is the MOST likely cause?
  • A. Her password was not complex enough
  • B. Her existing session and refresh tokens were not revoked
  • C. The organization uses SAML instead of OAuth
  • D. Her account was not added to an access review
  • 6. A defense contractor requires that documents be labeled Confidential, Secret, or Top Secret and that users can access only documents at or below their clearance level. Users cannot change labels or share documents with others. Which access control model is in use?
  • A. Discretionary
  • B. Role-based
  • C. Mandatory
  • D. Rule-based
  • 7. A security team wants to eliminate standing membership in the cloud Global Administrator role. Administrators should request the role when needed, receive approval, and lose it automatically after two hours. Which concept does this describe?
  • A. Time-based access control
  • B. Just-in-time access
  • C. Discretionary access control
  • D. Federation
  • 8. A company's password policy requires eight-character passwords with uppercase, lowercase, numbers, and symbols, changed every 60 days. Users frequently choose passwords such as Spring2026! and Summer2026!. Which changes align BEST with NIST SP 800-63B guidance? (Select TWO.)
  • A. Require password changes every 30 days
  • B. Increase minimum length and allow long passphrases
  • C. Add a requirement for two special characters
  • D. Screen new passwords against a list of compromised and common passwords
  • E. Require security questions for password resets
  • 9. A biometric system is adjusted so that it almost never accepts an impostor, but legitimate employees now frequently fail to authenticate. Which metric has increased?
  • A. False acceptance rate
  • B. False rejection rate
  • C. Crossover error rate
  • D. True positive rate
  • 10. A help desk receives a call from someone claiming to be the CFO, traveling and unable to use her phone, asking for her MFA to be reset. Which control BEST addresses the risk in this situation?
  • A. Password history
  • B. Strong identity proofing procedures for MFA resets, such as callback to a number on file
  • C. Rule-based access control
  • D. Increasing the TOTP code length
  • 11. Why are passkeys considered resistant to phishing?
  • A. They require users to remember a complex password
  • B. The private key is stored on the server and never transmitted
  • C. The credential is bound to the legitimate site's origin, so it cannot be used on a lookalike domain
  • D. They use SMS to deliver a one-time code
  • 12. An organization creates two highly privileged cloud accounts that are excluded from conditional access policies, protected by FIDO2 keys stored in separate safes, and configured to trigger an immediate alert whenever they are used. What type of account is this?
  • A. Service account
  • B. Third-party account
  • C. Emergency access account
  • D. Shared user account

Answers and Explanations

  • 1. C. SAML uses digitally signed XML assertions passed from an identity provider to a service provider for web SSO, exactly as described. LDAP is a directory protocol, OAuth 2.0 uses JSON tokens for delegated authorization, and Kerberos uses tickets within an internal realm rather than XML assertions to third-party websites.
  • 2. B. OAuth 2.0 allows a user to grant an application limited, scoped access to resources on another service without sharing a password; the consent screen and limited token are hallmarks. SAML is for web SSO with XML assertions, LDAP queries directories, and RADIUS provides network access AAA.
  • 3. A, C. This is MFA fatigue (push bombing). Number matching forces the user to enter a code shown on the real sign-in screen, which they cannot do for an attacker's attempt. FIDO2 passkeys or security keys are phishing-resistant and eliminate push approvals entirely. Password expiration does not address push abuse, SMS OTP is weaker and vulnerable to SIM swapping and phishing, and disabling lockout makes guessing easier.
  • 4. B. LAPS assigns a unique, random, regularly rotated local administrator password to each machine, preventing lateral movement with a single shared credential. Adding workstations to Domain Admins is nonsensical and dangerous. Complexity alone leaves the same password on every machine. Disabling the domain administrator account does not address local accounts.
  • 5. B. Disabling an account prevents new sign-ins but may not end existing sessions or invalidate refresh tokens on mobile apps. Deprovisioning should include session and token revocation. Password complexity is irrelevant after disabling, the protocol choice does not explain the issue, and an access review is periodic and would not prevent immediate post-termination access.
  • 6. C. Labels, clearances, and the inability of users to change or share access are the defining features of mandatory access control. In DAC, owners decide; in role-based access, job roles determine access; rule-based access applies administrator-defined global rules.
  • 7. B. Granting a privilege on request, with approval, for a limited time and then removing it automatically is just-in-time access, which eliminates standing privilege. Time-based access control restricts access to fixed windows such as business hours rather than granting temporary elevation on demand.
  • 8. B, D. NIST SP 800-63B emphasizes length (allowing long passphrases) and screening against blocklists of common and compromised passwords. More frequent expiration and extra composition rules encourage predictable patterns like those described. Security questions are not permitted as an authenticator or recovery method under NIST guidance.
  • 9. B. Increasing sensitivity lowers the false acceptance rate (impostors accepted) but raises the false rejection rate (legitimate users rejected). The crossover error rate is a fixed characteristic of the system used to compare accuracy, not something that rises with a sensitivity setting.
  • 10. B. The risk is social engineering of the help desk to take over an account by resetting MFA. Strong identity proofing—callback to a number on file, manager verification, or video verification—addresses it. Password history, rule-based access control, and TOTP length do not verify the caller's identity.
  • 11. C. Passkeys are bound to the relying party's origin; the browser and authenticator will not use a credential registered for the real domain on a lookalike domain, and signatures are tied to the origin. Passkeys do not involve passwords or SMS, and the private key stays on the user's authenticator—the server stores only the public key.
  • 12. C. Break-glass (emergency access) accounts are highly privileged accounts kept for when normal access fails, excluded from policies that could lock them out, stored securely, and heavily monitored. Service accounts are used by applications, third-party accounts belong to vendors, and shared user accounts are a practice to avoid, not a deliberate emergency control.
Use ← → to move between sections