Objective 4.6: Given a scenario, implement and maintain identity and access management

Cert: CompTIA Security+ (SY0-701) Domain: 4.0 Security Operations Weight: ~28% of SY0-701 (Domain 4 total) Depth: Implement. Be able to read a scenario about an account lifecycle, access-control decision, SSO or federation break, MFA gap, or privileged-account exposure, and name the right control to put in place.

What this objective tests

You should be able to read a scenario (a stale offboarded account that still works, a help desk reset that bypassed verification, a phished TOTP code, a long-lived domain admin password sitting in a spreadsheet, a contractor who needs short-term access to a partner app) and name the IAM control that should have been there. The objective is broad. It covers the full account lifecycle (provisioning, identity proofing, permission assignment, periodic attestation, deprovisioning), the five access-control models (MAC, DAC, RBAC, RuleBAC, ABAC plus time-of-day restrictions and least privilege), federation and SSO (LDAP, SAML, OAuth, OIDC, interoperability, attestation of trust), multifactor authentication (biometrics, hard tokens, soft tokens, security keys, the three classic factors plus location), password best practices and passwordless, and privileged access management (just-in-time access, password vaulting, ephemeral credentials).

This is the operational center of gravity for Domain 4. SP-4.5 enterprise capabilities and SP-4.7 automation both depend on the identity model defined here. If IAM is broken, every other control downstream is undermined.

Key facts

The account lifecycle and identity proofing

Every identity goes through Joiner-Mover-Leaver (JML). Joiner provisions the account and grants initial role access. Mover adjusts access as the user changes roles, removing old role permissions in the same pass. Leaver disables access on departure. Same day matters. Stale Leaver accounts (the marketing intern from three years ago whose account still works) are one of the most common breach footholds and one of the easiest findings in any IAM audit.

Identity proofing happens at provisioning and at high-risk events like password reset. NIST SP 800-63A defines three identity assurance levels.

The exam loves the password-reset bypass scenario. A help desk tech resets a password and gives the account back without verifying identity. The control is identity proofing at the reset step. Pair the reset with an MFA re-enrollment to harden it further.

Periodic attestation is the long-term cleanup control. A manager reviews the account list quarterly and signs off that each account still belongs and still has the right access. Unattested accounts get automatically disabled. Most identity audits surface the same finding: attestation runs once, then gets forgotten when the responsible manager changes roles. A backup attester per group is the fix.

Permissions, privileges, and least privilege

A permission is a specific allowed action (read folder, edit row, restart service). A privilege is a higher-level permission, usually tied to admin or service accounts that can change the system itself. Least privilege says: give exactly the access needed, no more. Permissions creep over time as people change roles and old permissions never get revoked. Attestation is the cleanup mechanism that catches creep before it becomes a finding.

Access-control models

Five models cover almost every access decision.

MAC is the strictest. DAC is the most flexible. RBAC is the practical default in most enterprises. RuleBAC handles the network and time-of-day edges. ABAC is the most expressive and is the engine that makes Zero Trust conditional access work.

ABAC evaluates the user, the resource, the action, and the context together. A typical ABAC policy: allow access to the HR data warehouse IF the user has role 'HR Analyst' AND the device is compliant AND the location is the United States AND the time is between 06:00 and 22:00 local AND the request type is read-only. NIST SP 800-162 (Guide to Attribute Based Access Control) is the canonical reference.

Time-of-day restriction is named separately on the objective. It is a RuleBAC pattern most commonly seen in banking and healthcare, where after-hours access requires elevated approval.

SSO, federation, and the protocols

SSO (Single Sign-On) means the user authenticates once to the identity provider (IdP), and the IdP issues assertions or tokens to each app. The app trusts the IdP, not the password. SSO improves both security and user experience. One strong sign-in protects many downstream apps.

Federation extends SSO across organizational boundaries. A contractor at a partner firm signs in to their home IdP and accesses an app at your organization because your app trusts their IdP. Periodic attestation of the federation trust (often signed by a partner-relationship owner) is the underrated control.

Four protocols drive the implementation.

OAuth alone is authorization, not authentication. The app gets a token to act on the user's behalf but does not actually know who the user is. OIDC layers on top by adding the ID token. This is the most common exam trap: do not confuse OAuth (authorization) with authentication. SAML 2.0 handles both authentication and authorization through the same signed assertion.

Interoperability matters. Most modern identity stacks speak both SAML and OIDC. Bridge platforms (Microsoft Identity Platform, Auth0, Ping Identity) translate between protocols so a legacy SAML app can sit behind a modern OIDC stack.

Multifactor authentication

MFA requires two or more factors from different categories.

Two of the same factor is not MFA. Password plus security question is not MFA (both are know). Password plus PIN is not MFA. The exam tests this directly.

Implementations matter.

• Biometrics. Convenient. Cannot be changed if leaked. False acceptance rate (FAR) and false rejection rate (FRR) tune the tradeoff. Apple Face ID and Windows Hello are the common examples.
• Soft tokens. TOTP (Time-based One-Time Password, RFC 6238) in an authenticator app (Microsoft Authenticator, Google Authenticator, Authy). 6-digit code that rotates every 30 seconds. Easy to deploy. Vulnerable to phishing because a user can be tricked into reading the code on a fake page. Push notifications add 'push fatigue' as a real attack (user clicks approve without looking).
• Hard tokens. Dedicated hardware. RSA SecurID, YubiKey OTP mode, smartcards. Stronger than soft tokens because the secret never leaves the hardware.
• Security keys (FIDO2 / WebAuthn). Phishing-resistant by design. The key uses public-key cryptography. The browser binds the challenge to the actual origin, so a phishing site cannot replay the response. YubiKey, Titan, and Windows Hello with TPM all implement FIDO2.
• SMS-based MFA. Better than no MFA, but the weakest factor. SS7 attacks and SIM swaps defeat it. NIST SP 800-63B has restricted SMS as an out-of-band authenticator since 2017.

Passwords and passwordless

NIST SP 800-63B updated the password guidance years ago and the modern rules surprise students.

Password managers (1Password, Bitwarden, Keeper, browser-native vaults) are the working default. They enable the long unique passwords per site that the new guidance requires.

Passwordless is the destination. FIDO2 / WebAuthn passkeys remove the password entirely. The user proves possession of the device with a touch or biometric, and the device signs a challenge with a private key that never leaves the device. There is nothing to phish, nothing to spray, nothing to reuse. Apple, Google, Microsoft, and the FIDO Alliance all back the standard, and most major sites now support passkeys for sign-in.

Privileged Access Management (PAM)

Privileged accounts (domain admin, root, cloud root, service accounts that own production systems) are the most dangerous credentials in any organization. PAM tools enforce three controls.

• Password vaulting. Privileged credentials live in a secured vault. The admin checks them out for a session and checks them back in. The vault auto-rotates the password after every use. No long-lived admin password sits on a laptop or in a spreadsheet.
• Just-in-time (JIT) access. The privilege is granted only for the moment it is needed, often through an approval workflow, then automatically removed. Entra Privileged Identity Management (PIM) and AWS IAM Identity Center session policies are the cloud-native examples.
• Ephemeral credentials. Short-lived tokens or passwords that expire automatically. Cloud STS tokens expire in an hour. SSH certificates expire in minutes. The admin never holds a long-lived credential.

CyberArk, BeyondTrust, Delinea, and HashiCorp Vault are the leading on-prem and cloud-agnostic PAM platforms. Entra PIM, AWS IAM Identity Center, and GCP just-in-time access are the cloud-native equivalents. The pattern is the same regardless of vendor: vault the secret, grant just-in-time, expire automatically, audit every session.

Common gotchas

• Two passwords is not MFA. Same factor twice does not count. Same with password plus security question (both are 'know'). The exam tests this directly.
• OAuth is authorization, not authentication. Apps get tokens to act on a user's behalf but do not know who the user is unless OIDC is layered on top. This is the most common federation-protocol miss.
• SAML and OIDC are both federation. SAML uses XML. OIDC uses JSON. Both ship in modern stacks. Picking one over the other is usually an app-vendor decision, not a security decision.
• Stale accounts are the easy finding. Every IAM audit surfaces accounts whose owners left the company months or years ago. The Leaver step plus quarterly attestation is the control.
• Identity proofing at password reset is the control for help-desk-reset bypass. The exam loves this scenario. A reset that does not verify identity is a free account takeover.
• SMS-based MFA is weakest. NIST has restricted it as an out-of-band authenticator since 2017. Better than nothing, but soft tokens are stronger and security keys are stronger still.
• FIDO2 is phishing-resistant. TOTP is not. The browser binds the FIDO2 challenge to the actual origin. A phishing site cannot replay the response. The user can still type a TOTP into a fake page.
• Long-lived admin passwords are technical debt. PAM with vaulting, JIT, and ephemeral credentials is the modern pattern. A privileged password rotating every 90 days is not modern PAM.
• ABAC is the conditional access engine. When the scenario mentions device posture, location, time, and resource sensitivity in the same access decision, it is ABAC. NIST SP 800-162 is the canonical reference.
• Time-of-day restriction is RuleBAC. Named on the objective. Common in banking and healthcare. After-hours access requires elevated approval.
• Attestation of federation trusts is the underrated control. Periodic re-confirmation that the trust is still appropriate, signed by a partner-relationship owner. Stale federation trusts are how a long-gone vendor still has API access to your environment.
• LDAP without TLS is a sniffable credential store. Production uses LDAPS on port 636 by default. LDAP on 389 is for testing only.

Real-world context

In a SOC seat, IAM shows up three ways. Sign-in alerts surface in the SIEM the moment an account behaves unusually (impossible travel, MFA failure spike, dormant account reactivation). The Tier 1 analyst correlates the sign-in with the user's HR status, group memberships, and recent activity. The disable button is one click. The investigation that follows answers how the account got compromised and which IAM control should have caught it sooner.

In a systems administration or cloud engineering seat, IAM is the daily backbone. Provisioning new joiners, running the Leaver workflow on the same day a termination is filed, executing the quarterly attestation campaign, rotating service accounts, configuring conditional access policies in the IdP, integrating new apps via SAML or OIDC. The work is mostly process and habit, not exotic tooling. Identity teams that build clean processes and stick to them have boring breach reports.

In a compliance and audit seat, IAM is the evidence trail. Cyber insurance underwriters and regulators (SOC 2, HIPAA, PCI-DSS, GLBA) all ask for the same artifacts. MFA coverage on privileged accounts. Quarterly attestation reports. Deprovisioning SLA evidence. PAM session recordings. Password policy alignment with NIST SP 800-63B. Federation trust review cadence. A small business that cannot produce these is increasingly uninsurable at any price and at risk of failed audits.

Zero Trust (NIST SP 800-207) lands every access decision at the identity plane. Identity is the control plane. Device posture, network location, and resource sensitivity are inputs. The decision engine is ABAC. The enforcement point is the conditional access policy at the IdP. Every access request authenticated, authorized, encrypted, and logged. IAM is what makes Zero Trust possible.

In a security architect or engineer seat, the work is design and validation. Pick the IdP. Pick the federation protocols. Build the RBAC role library. Set the MFA policy (phishing-resistant by default, exceptions documented). Deploy the PAM stack. Wire the attestation cadence. Then defend every choice against the next audit and the next penetration test. The win is not the perfect identity architecture. The win is the architecture that the business can run, that the team can attest to, and that the auditors can verify under realistic conditions.

Sources

• CompTIA Security+ SY0-701 Exam Objectives, Section 4.6
• NIST SP 800-63-3 Digital Identity Guidelines (parts A identity proofing, B authenticators, C federation)
• NIST SP 800-162 Guide to Attribute Based Access Control (ABAC)
• NIST SP 800-207 Zero Trust Architecture
• NIST SP 800-53 Rev 5 Security and Privacy Controls (AC, IA control families)
• RFC 6749 The OAuth 2.0 Authorization Framework
• RFC 6238 TOTP: Time-Based One-Time Password Algorithm
• OASIS SAML 2.0 Core specification
• FIDO Alliance FIDO2 / WebAuthn specifications
• OpenID Connect Core 1.0 specification