Security+ Identity and Access Management: SSO, MFA, PAM, and Automation

Introduction

This lesson completes the core of Domain 4, Security Operations (28% of SY0-701), with objective 4.6, implementing and maintaining identity and access management, and objective 4.7, explaining the importance of automation and orchestration related to secure operations. Security+ identity and access management covers how accounts are created, authenticated, authorized, elevated, and removed. Stolen credentials can bypass otherwise strong infrastructure controls, so identity security must work alongside endpoint and network defenses.

Automation is the second theme. Security teams cannot manually process thousands of alerts, accounts, and patches. The exam asks when automation helps (speed, consistency, scale), what it costs (complexity, technical debt, single points of failure), and how orchestration ties tools together.

Learning objectives

After this lesson you will be able to:

• Describe the identity life cycle: provisioning, de-provisioning, and access reviews.
• Compare SSO, federation, SAML, OAuth, OpenID Connect, LDAP, and Kerberos at a conceptual level.
• Select authentication factors and MFA methods, and explain password best practices and passwordless options.
• Compare access control models: MAC, DAC, RBAC, ABAC, rule-based, and time-of-day restrictions.
• Implement privileged access management with just-in-time permissions, vaulting, and ephemeral credentials.
• Identify use cases, benefits, and risks of automation, and explain scripting and orchestration.

1. Provisioning and de-provisioning

Provisioning creates an identity and gives it the access needed for the job: an account, group memberships, licenses, mailbox, and applications. De-provisioning removes or disables access when the person leaves or changes role. Weak de-provisioning produces orphaned accounts and privilege creep, where a person who changes roles keeps access from every earlier job.

Good practice:

• Drive provisioning from an authoritative source such as the HR system, with automated joiner-mover-leaver workflows.
• Grant access by role and approve exceptions.
• Disable access at the authorized termination time, revoke sessions and tokens where supported, and rotate credentials or shared secrets the leaver knew. Delete identities only under approved retention and preservation rules. Verify downstream application access, since disabling the IdP alone may leave existing sessions active.
• Perform periodic access reviews (recertification): managers confirm who still needs which access.
• Maintain separation of duties so no one person can complete a sensitive process alone.
• Apply least privilege and need to know.
• Verify the identity of the user before provisioning, called identity proofing, and apply user ID and password reset checks to avoid social engineering.
• Track service and non-human accounts with owners and credential rotation, since they are often forgotten.

Example 1: the mover problem

A payroll clerk moves to procurement. Nobody removes payroll access, so within a year the same account can create vendors and approve payments, violating separation of duties. An automated "mover" workflow that removes old-role entitlements, plus a quarterly access review, would have caught it. This is a classic cause of fraud findings in audits.

2. Single sign-on and federation

Single sign-on (SSO) lets a user authenticate once and access multiple systems without logging in again. Benefits are fewer passwords, a central place to enforce MFA, and quicker de-provisioning. The risk is concentration: compromise of an SSO identity can expose the applications and entitlements available to that identity, so protect it with strong MFA and monitoring.

Federation extends trust between organizations or domains so identities from one party (the identity provider, IdP) are accepted by another (the service provider, SP or relying party), without sharing passwords.

A quick memory trick: OAuth answers "what may this app do?" (authorization); OpenID Connect and SAML answer "who is this user?" (authentication).

ID tokens and assertions require issuer, audience, signature, and validity checks; they are not permission to access every resource. Review the cryptographic trust and certificate foundations used by these protocols.

3. Authentication factors and MFA

Factors:

• Something you know: password, PIN, passphrase.
• Something you have: hardware token, smart card, authenticator app, phone, security key.
• Something you are: fingerprint, face, iris (biometrics).
• Context signals: location and network can inform conditional access, but do not become an independent NIST authentication factor by themselves.
• Behavioral characteristics: typing rhythm or gait may support a biometric or risk assessment; do not count ordinary behavior telemetry as an additional factor automatically.

Multifactor authentication (MFA) requires factors from at least two different categories. Two passwords are not MFA. A password plus a security question is not MFA, because both are knowledge.

Compare methods by threat rather than one universal ranking. SMS and voice face telecom risks; manually entered email or TOTP codes can be relayed by phishing. Push approvals can face MFA fatigue; number matching reduces approval abuse but is not phishing resistance. A hardware OTP token is still relayable. FIDO2/WebAuthn security keys and passkeys provide site-bound cryptographic authentication; require the appropriate user verification to meet the desired MFA assurance.

Biometrics concepts: FAR (false acceptance rate, an impostor is accepted), FRR (false rejection rate, a valid user is rejected), and CER/EER (the crossover where FAR equals FRR; lower is better). Biometric characteristics are difficult to replace and are not secrets. Under NIST guidance, use biometrics with a physical authenticator; evaluate spoof resistance and the operating threshold rather than relying only on CER/EER.

Password guidance (NIST SP 800-63B, 2025 revision): length over complexity, screen against breached-password lists, allow passphrases and paste, and do not force periodic changes without evidence of compromise. For NIST-conforming deployments, centrally verified single-factor passwords require at least 15 characters; passwords used only within MFA may have an eight-character minimum. Support password managers. Protect against brute force with lockout or throttling and monitor for credential stuffing. Passwordless options can remove the server-verified user password; private keys, device-unlock secrets, recovery, and session protection still matter.

Conditional or adaptive access adjusts requirements by risk: new device, new country, or impossible travel triggers step-up MFA or blocks access.

Worked example: choosing MFA for administrators

Scenario. A company's cloud administrators have been targeted by phishing proxies that capture passwords and one-time codes in real time. Management wants an MFA method that defeats this. Options: (A) SMS codes, (B) TOTP authenticator app, (C) FIDO2 security keys, (D) a longer password.

Reasoning.

1. Real-time phishing proxies relay whatever the user types, including SMS and TOTP codes, to the real site while the attacker is connected.
2. SMS (A) is also exposed to SIM swapping. TOTP (B) is better than SMS but still phishable by relay.
3. FIDO2/WebAuthn (C) binds the credential to the relying party, and the server validates the challenge and origin. A look-alike origin cannot obtain an assertion valid for the legitimate relying party under that protocol. This does not protect a stolen session or a compromised endpoint.
4. A longer password (D) is still a knowledge factor and does nothing against proxies.

Solution. C, FIDO2/WebAuthn security keys (with a backup key and a controlled recovery process).

4. Access control models

Related ideas: least privilege, conditional access, geofencing, ACLs on files and network resources, and role-based assignment of administrative duties. An access control list specifies permissions on a resource; order and conflict handling depend on the platform. permission inheritance can cause surprises when moving folders.

5. Privileged access management (PAM)

Privileged accounts (domain admin, root, cloud owner, database admin) have the highest impact and are the primary target. PAM controls them:

• Just-in-time (JIT) permissions: elevate only when needed and for a limited time, rather than holding standing administrator rights.
• Password vaulting: store privileged credentials in a vault, check them out with approval, and rotate them automatically after use.
• Ephemeral credentials: short-lived secrets or tokens that expire automatically.
• Session recording and monitoring: capture what the administrator did.
• Separate admin accounts from daily-use accounts, and use privileged access workstations.
• Break-glass accounts: emergency accounts stored securely, tightly monitored, and used only when normal systems fail.
• Multi-person approval for the most sensitive actions.
• Secrets management for application credentials, API keys, and certificates, instead of embedding them in code.

Example 2: eliminating standing domain admin

An engineering firm finds 38 permanent domain administrators, many of whom use that account for email. After a ransomware drill demonstrates that one phished administrator would give an attacker the whole domain, the company moves to a PAM platform: administrators log in with normal accounts, request elevation with a ticket number, receive an approved two-hour elevation or short-lived credential, and administrative sessions are recorded. The workflow also revokes elevation and terminates or reauthorizes active privileged sessions at expiry; vault checkout alone does not guarantee those effects. Standing domain admins drop from 38 to 3 break-glass accounts.

Tie privilege approvals and exceptions to security policies and risk ownership.

6. Automation and orchestration

Automation executes a task without manual steps. Orchestration coordinates multiple automated tasks and tools across systems into a workflow. A SOAR platform is the typical security example: it receives an alert from the SIEM, enriches it with threat intelligence, checks the user and endpoint, isolates the host through the EDR, opens a ticket, and notifies the on-call analyst.

Use cases listed in the objectives

• User and resource provisioning.
• Guard rails and security groups (automatic enforcement of policy limits).
• Ticket creation and escalation.
• Enabling and disabling services and access.
• Continuous integration and testing (CI/CD pipelines that scan code and infrastructure).
• Integrations and APIs between tools.

Benefits

• Efficiency and time saved on repetitive work.
• Enforcing baselines and consistent configuration.
• Standardized infrastructure configurations.
• Scaling in a secure manner.
• Employee retention (analysts spend time on higher-value work).
• Reaction time (seconds, not hours).
• Workforce multiplier.

Considerations and risks

• Complexity: automations need design, review, and documentation.
• Cost of tools and engineering effort.
• Single point of failure: if the orchestration platform is down or its credentials are stolen, many systems are affected.
• Technical debt: scripts that nobody maintains break when systems change.
• Ongoing supportability: the team must be able to maintain and troubleshoot it.
• Over-automation of sensitive actions without human approval can cause outages; for high-impact actions use a human-in-the-loop checkpoint.
• Automation accounts need least privilege and secured credentials.

Scripting (PowerShell, Python, Bash) is the common way to build automation. Secure scripting practices: store secrets in a vault, validate input, log actions, use version control and code review, test in non-production, and sign scripts.

Worked example: automating phishing response

Scenario. The SOC receives about 200 user-reported phishing emails per week. Each takes 20 minutes: check headers, detonate attachments, search for other recipients, delete messages, and block the sender. Design an automation.

Reasoning.

1. The user clicks a "report phish" button which creates a ticket through the mail platform's API.
2. A SOAR playbook extracts URLs and attachments, checks them against threat intelligence, and detonates files in a sandbox.
3. For a high-confidence malicious verdict, the playbook finds matching message identifiers or fingerprints and quarantines matching mail within approved scope. Block specific malicious URLs or senders as appropriate; a blanket domain block could interrupt a legitimate shared service or compromised supplier.
4. For clicked links, it checks credential entry, token/session abuse, endpoint activity, and user confirmation. Apply account/session containment according to that evidence and the playbook; a URL visit alone does not establish credential theft.
5. For ambiguous verdicts it escalates to an analyst rather than acting automatically.
6. The playbook runs with a least-privilege service account whose credentials are in a vault and all actions are logged.

Solution. A SOAR playbook with API integrations, automated enrichment and containment, and a human decision point for uncertain cases. Why not fully manual? It does not scale and delays containment. Why not unattended deletion of everything flagged? False positives would delete legitimate business mail.

A reporting workflow also depends on phishing awareness and user reporting so analysts receive useful context.

7. Comparison: choosing the right identity control

8. Common pitfalls

• Treating two knowledge factors as MFA.
• Assuming SMS or push approvals are phishing-resistant.
• Confusing OAuth (authorization) with OpenID Connect/SAML (authentication).
• Leaving standing privileged access and shared administrator accounts.
• Forgetting service accounts and API keys in de-provisioning.
• Automating a broken process, which just breaks faster.
• Giving the automation platform excessive privileges and no logging.
• Skipping access reviews because the HR feed is "automatic".

9. Exam tips

• "Once, many applications" means SSO; "across organizations" means federation.
• "Delegated access to data with tokens" means OAuth.
• "Role-based" means permissions by job role; "attributes and policy" means ABAC; "labels and clearances" means MAC; "owner decides" means DAC.
• "Temporary elevation" means just-in-time access under PAM.
• "Employee changed departments and kept access" means privilege creep, solved by reviews and mover workflows.
• "Real-time phishing" points to FIDO2.
• For automation, remember the trade-off: gains in speed and consistency versus complexity, cost, and single point of failure.

10. Mini case study

Case. Litware Retail has 900 staff. Audit findings: (1) 60 accounts belong to people who left over six months ago; (2) store managers who became regional managers still have store system access; (3) helpdesk resets passwords after a phone call using the employee's date of birth; (4) 25 engineers hold permanent cloud owner rights; (5) analysts manually close about 300 low-risk alerts per day.

Tasks. Recommend fixes.

Solution.

1. Connect HR to the identity system for automated leaver workflows that disable accounts, revoke tokens, and notify application owners; disable the 60 stale accounts now and investigate any recent sign-ins.
2. Add mover workflows and quarterly access recertification by managers.
3. Replace date-of-birth checks with an approved recovery workflow using previously bound authenticators or renewed proofing at the required assurance. A callback or manager approval can support the process but should not be treated alone as phishing-resistant proof. Log recovery and notify the account owner.
4. Adopt PAM: JIT elevation, vaulted credentials, session recording, and two break-glass accounts.
5. Use SOAR to enrich and auto-close well-understood low-risk alert types with logging, keeping human review for new or high-risk categories. Review the playbooks periodically to avoid technical debt.
6. Roll out SSO with phishing-resistant MFA for administrators and MFA for other users, preferring phishing-resistant methods where supported and securing enrollment and recovery.

Key terms

• Provisioning / de-provisioning: creating and removing identities and access.
• Privilege creep: accumulation of access over time.
• SSO / federation: one login for many systems and cross-domain trust.
• IdP / SP: identity provider and service provider.
• SAML, OAuth, OpenID Connect: federation and delegation standards.
• MFA: authentication using two or more factor categories.
• FIDO2 / passkey: phishing-resistant credential bound to a site.
• RBAC, ABAC, MAC, DAC: access control models.
• PAM / JIT: privileged access management and just-in-time elevation.
• Break-glass account: emergency privileged account.
• SOAR / orchestration: automated workflow across tools.
• Technical debt: future maintenance cost from shortcuts.

Summary checklist

• I can describe joiner-mover-leaver processes and why access reviews matter.
• I can explain SSO and federation and distinguish SAML, OAuth, and OpenID Connect.
• I can classify authentication factors and choose phishing-resistant MFA.
• I can compare RBAC, ABAC, MAC, DAC, and rule-based control.
• I can explain JIT access, vaulting, ephemeral credentials, and break-glass accounts.
• I can list automation use cases, benefits, and risks.
• I can design a SOAR workflow with human approval for high-impact actions.

Sources

• CompTIA Security+ V7 objectives summary (opens in a new tab) — objectives 4.6–4.7.

• NIST SP 800-63B, Digital Identity Guidelines: Authentication and Lifecycle Management: https://pages.nist.gov/800-63-4/sp800-63b.html (opens in a new tab)

• NIST SP 800-53 Rev. 5, controls AC (Access Control) and IA (Identification and Authentication): https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final (opens in a new tab)

• FIDO Alliance, FIDO2 overview: https://fidoalliance.org/fido2/ (opens in a new tab)

• OpenID Foundation, OpenID Connect Core: https://openid.net/specs/openid-connect-core-1_0.html (opens in a new tab)

• CISA, Implementing Phishing-Resistant MFA: https://www.cisa.gov/resources-tools/resources/implementing-phishing-resistant-mfa (opens in a new tab)

• RFC 8907: TACACS+ security and obfuscation (opens in a new tab)