Identity & Access Management (IAM)
Provisioning, federation, SSO, MFA, access-control models (MAC/DAC/RBAC/ABAC), password policy, and privileged access management — the plumbing that decides who can do what.
Identity is the new perimeter. With the traditional network edge dissolved by cloud and remote work, IAM controls are often the last (and only) line of defense. Security+ 4.6 tests the full lifecycle (provisioning → attestation → deprovisioning), the access-control models (MAC, DAC, RBAC, ABAC, rule-based), authentication strength (MFA with real factors, not instances), modern password guidance (NIST SP 800-63B), and the privileged-account disciplines that keep admin power safe (PAM, JIT access, ephemeral credentials, password vaulting).
The exam’s favorite traps: MFA requires multiple factors, not multiple instances (password + PIN is one factor twice, not MFA). SAML authenticates; OAuth authorizes — they often work together. NIST current guidance deprecates forced periodic rotation — length and uniqueness beat complexity theater. MAC (mandatory access control) is not the same MAC as media access control in networking — context matters.
Provisioning and deprovisioning. Accounts are created at hire (joiner), modified on role change (mover), and disabled on termination (leaver). The JML workflow should be automated: HR system of record → IAM platform → target systems. Orphaned accounts — active credentials for people who left — are among the highest-value targets for attackers and insiders.
Permission assignments and implications. Least privilege: each account gets only what its role requires. Review regularly (quarterly attestation is common); remove on role change (access creeps as people move roles). Separation of duties splits sensitive tasks across people so no one person can complete a fraud.
Identity proofing. Verifying a person is who they claim at account creation. KYC processes, government ID checks, phone/email verification, in some sectors biometric enrollment. This is the foundation: every later authentication rests on the identity being real in the first place.
Federation. Trust between identity providers (IdPs) using protocols like SAML or OIDC. A user authenticates at their home IdP once and access flows to partner applications. Federation is how modern SaaS SSO works: Okta / Entra ID / Ping authenticates; Salesforce / Slack / GitHub accept assertions.
Single sign-on (SSO). One authentication, many apps. Core protocols:
- LDAP — directory protocol for lookups and bind-based authentication (Active Directory’s underpinnings).
- OAuth 2.0 — authorization framework. Delegates API access without sharing credentials.
- OIDC (OpenID Connect) — authentication layer on top of OAuth 2.0. Modern web SSO often uses OIDC.
- SAML — XML-based authentication/federation. Dominant in enterprise SSO.
Interoperability. Standards-based federation (SAML, OIDC) lets platforms from different vendors trust each other. Proprietary auth isolates you.
Attestation. Periodic reaffirmation of access. Managers review their team’s entitlements quarterly or annually and sign off — the control that catches access creep and orphaned accounts.
Access controls — the models.
- Mandatory Access Control (MAC) — system-enforced labels (Top Secret, Secret, Confidential). Users cannot override. Common in government and high-assurance environments.
- Discretionary Access Control (DAC) — owner decides. Standard in operating systems (a file owner can grant access to anyone they choose).
- Role-based Access Control (RBAC) — permissions attach to roles; users are assigned roles. Most business apps work this way.
- Rule-based — decisions follow rules (time-of-day, network zone, geo). Often combined with RBAC.
- Attribute-based Access Control (ABAC) — decisions use attributes of the user, resource, action, and environment. Flexible; policy-language expressive.
- Time-of-day restrictions — allow only during business hours.
- Least privilege — minimum access for the task; revoke unused.
Multi-factor authentication (MFA). The factors (categories):
- Something you know — password, PIN.
- Something you have — TOTP app, hard token (YubiKey, RSA SecurID), smart card.
- Something you are — biometric (fingerprint, face, iris). Accuracy metrics: False Accept Rate, False Reject Rate, Crossover Error Rate.
- Somewhere you are — geolocation / IP range.
Real MFA uses factors from different categories. Password + PIN is one factor twice (both “know”) and does not count. Implementations include biometrics, hard tokens, soft tokens (TOTP), and security keys (FIDO2 / WebAuthn — phishing-resistant by design).
Password concepts — NIST SP 800-63B current guidance.
- Length matters more than complexity; 15+ characters preferred.
- Complexity rules (must have symbol, must have number) are de-emphasized.
- Reuse is checked against breach corpora; compromised passwords are banned.
- Expiration — NIST says do not force periodic rotation unless compromise is suspected.
- Age (minimum) — prevents rapid-cycle-through-history to bypass “do not repeat last 5.”
- Password managers generate and store unique strong passwords.
- Passwordless — FIDO2/WebAuthn, certificate-based, magic links — the trajectory.
Privileged Access Management (PAM). Disciplines for admin accounts:
- Just-in-time (JIT) permissions — elevate only when needed, for a bounded time window, with approval and audit.
- Password vaulting — admin passwords in a vault; check-out / check-in with logging.
- Ephemeral credentials — short-lived, auto-rotating credentials (AWS STS, HashiCorp Vault dynamic secrets).
- Session recording — capture privileged sessions for audit.
| Model | Who Decides | Typical Setting |
|---|---|---|
| MAC (Mandatory) | System — labels enforced, users cannot override | Government classified systems |
| DAC (Discretionary) | Resource owner | Default OS file permissions |
| RBAC (Role-based) | Roles, assigned by admin | Most business applications |
| Rule-based | Rules (time, network, geo) | Combined with RBAC for context |
| ABAC (Attribute-based) | Policy evaluating attributes | Fine-grained cloud IAM |
| Factor Category | Examples | Strengths / Weaknesses |
|---|---|---|
| Something you know | Password, PIN, security question | Cheap; phishable, reusable, guessable |
| Something you have | TOTP app, hard token, smart card, security key | Possession-based; FIDO2 keys are phishing-resistant |
| Something you are | Fingerprint, face, iris | Hard to steal; FAR/FRR tradeoff; not revocable |
| Somewhere you are | GPS, IP geolocation | Context signal; not stand-alone sufficient |
| Protocol | Does | Common Use |
|---|---|---|
| SAML | Authentication + federation (XML assertions) | Enterprise SSO into SaaS |
| OAuth 2.0 | Authorization (delegated API access, no password sharing) | “Sign in with” flows, API tokens |
| OIDC | Authentication layer built on OAuth 2.0 | Modern web SSO |
| LDAP / LDAPS | Directory lookup + bind-auth | On-prem AD, UNIX auth |
| Kerberos | Ticket-based auth (often behind AD) | Windows domain auth |
| FIDO2 / WebAuthn | Phishing-resistant hardware/platform auth | Passwordless, security keys |
Three rules run 4.6. (1) Real MFA uses factors from different categories — password + PIN is not MFA. (2) SAML = auth/federation, OAuth = authorization, OIDC = auth on top of OAuth. (3) NIST no longer mandates periodic rotation — length and breach-corpus checks replaced it.
A mid-size engineering org has 40 engineers with standing admin access to the cloud production environment. Security audit flagged this as excessive. The engineering lead argues that debugging requires fast access; any friction kills incident response. The security team proposes PAM with just-in-time elevation. Both are right in a sense — the question is how to reconcile.
40 engineers with standing prod admin — audit fail
Cloud prod · standing admin · PAM proposalJIT elevation with break-glass preserves speed without preserving risk. Engineers get in within seconds; credentials are ephemeral; every elevation is logged and time-bounded. Routine automation uses its own machine identity with just-enough permissions. Standing admin access becomes the exception, not the norm.
PAM rollouts succeed or fail on user experience. A perfect JIT design that takes three minutes to elevate will be bypassed on day one. Design for sub-30-second normal path + break-glass for incidents + honest audit trail. Security that slows people down during fires is security that gets uninstalled.
On the exam: “admin access for contractors” / “elevate only when needed” → JIT + PAM. “short-lived credentials auto-rotated” → ephemeral credentials.
A banking app prompts for username, password, and a 6-digit SMS code on every login. The product team proposes adding a mandatory security question (“What was your first pet?”) as an additional check. Marketing calls this “tri-factor authentication.” Which statement is the correct security evaluation?
Adding the security question upgrades the flow from 2FA to 3FA
More factors = stronger security. Label accordingly and market the benefit.
The security question is the same factor category as the password; the login remains 2FA
Both password and security question are “something you know.” The code is “something you have” — that is the second factor.
Option B fits better — factors are categories, not instances
Option B: MFA strength comes from using different factor categories, not from the count of prompts. Password + security question = “something you know” twice — still one factor. Adding “something you are” (biometric) or a second “something you have” (security key) would be a true third factor.
Option A’s kernel of truth: More questions feels more secure. The Security+ exam, NIST, and common sense classify this as the same factor used twice.
On the exam: “password + PIN” = same factor, not MFA. “password + TOTP” = different factors, valid MFA.
4.6 tests four patterns: (1) real MFA uses different factor categories — password + PIN is not MFA; (2) protocol roles — SAML authenticates/federates, OAuth authorizes, OIDC is auth on OAuth; (3) NIST modern password guidance deprecates forced periodic rotation in favor of length and breach corpus; (4) PAM disciplines — JIT elevation and ephemeral credentials replace standing admin access for sensitive operations.
- A Valid MFA — two independent steps
- B Not MFA — both are “something you know”
- C Valid MFA because of the security question
- D Not authentication at all
Correct: B. MFA requires factors from different categories. Password and security question are both knowledge factors.
Source: CompTIA SY0-701 Objectives v5.0 — 4.6
- A Each user creates a new password on the SaaS platform
- B Federation via SAML or OIDC: the SaaS platform is the service provider, Okta is the identity provider
- C Shared admin account for all of the customer’s users
- D Network-level IP allow-list in place of authentication
Correct: B. SAML or OIDC federation is the standard pattern for enterprise SSO into SaaS. The customer’s IdP asserts identity; the SaaS platform consumes the assertion.
Source: CompTIA SY0-701 Objectives v5.0 — 4.6
- A Require a manager email for every production change
- B Implement JIT elevation via PAM with break-glass for on-call, ephemeral credentials, and session logging
- C Remove admin access entirely and route all work through tickets
- D Rotate the shared admin password monthly
Correct: B. JIT + break-glass + ephemeral credentials gives fast access with full audit trail and no standing privilege. Email-approval slows response; total removal breaks ops; shared password is an anti-pattern.
Source: CompTIA SY0-701 Objectives v5.0 — 4.6