CompTIA Security+ SY0-601: How to Implement Identity and Account Management Controls in Real Scenarios

Austin Davies -

1. Why Identity and Account Management Matters

In Security+, identity and account management is really about controlling access over time. It’s not one of the CIA triad pillars on its own, but it absolutely helps protect confidentiality, integrity, and accountability. If an attacker gets hold of a valid identity, honestly, they often don’t need some fancy exploit at all. They log in, inherit trust, and move through systems as if they belong there. That is why IAM is not just a password topic. Honestly, it’s the whole lifecycle: figuring out who someone is, proving they’re really that person, deciding what they can access, keeping privileges from creeping upward, managing the account from day one to day last, and making sure you’ve got a clean audit trail when you need it later.

I usually keep it pretty simple, really: who’s the person, how do we verify them, what can they access, what rules apply while they’re using it, and how do we prove what happened afterward? Those questions show up constantly on the exam and in real incidents. Common failures include stale accounts, missing MFA on admin portals, delayed offboarding, shared admin credentials, and service accounts with excessive rights.

Security+ exam tip: If the scenario is really about access scope, duration, or traceability, think IAM lifecycle, least privilege, and logging before you think “just reset the password.”

2. AAA, Identification, and Core IAM Terms

Before AAA, there is one more concept worth separating: identification is the claim of identity, while authentication verifies that claim. Saying “I am jsmith” is identification. Proving it with a password, certificate, or security key is authentication.

The three A’s of AAA are:

Authentication: Who are you?
Authorization: What are you allowed to do?
Accounting: What did you do?

On modern systems, “accounting” is often implemented through auditing, logging, monitoring, and AAA records. In other words, the exam term is accounting, but in operations you will also hear audit trail, accountability, and security logging.

Example: a user signs in with a password and MFA. That is authentication. They can read a finance share but cannot delete files. That is authorization. The file server and SIEM record the access, timestamp, source IP, and changes made. That is accounting and auditing.

Concept: Identification
Meaning: Claiming an identity
Example: Entering username jsmith

Concept: Authentication
Meaning: Verifying identity
Example: Password plus MFA

Concept: Authorization
Meaning: Granting permissions or entitlements
Example: Read-only access via ACL or group

Concept: Accounting
Meaning: Logging and auditability
Example: A log shows who accessed what and when

Authorization usually shows up as permissions, entitlements, roles, groups, and access control lists, or ACLs, like we usually call them in practice. If someone can log in just fine but still can’t open the file, that’s usually an authorization issue, not an authentication issue. If the user can’t prove they are who they say they are at sign-in, then you’re looking at an authentication problem. If nobody can prove who changed the record, that is an accounting or auditing gap.

3. Account Types and Identity Sources You Need to Know

Security+ expects you to distinguish between account types because the right control depends on the identity involved.

Named user account: Used for daily employee access. The big risks here are phishing and giving people more access than they actually need. The first controls I’d reach for are MFA, least privilege, and regular access reviews. Those three solve a lot more problems than people think.

Privileged or admin account: Used for administrative tasks. The real danger is that if it gets compromised, the damage can be huge. Best controls include a separate account, PAM, MFA, and a privileged workstation.

Guest or vendor account: Used for external collaboration. The main risk is lingering access. Best controls include expiration, scope limits, and monitoring.

Service account: Used by applications and scheduled jobs. Main risks include hardcoded secrets and excessive privilege. Best controls include secret vaulting, least privilege, and blocking interactive logon.

Shared or generic account: Sometimes used in legacy or emergency situations. The main risk is loss of accountability. Best practice is to avoid these accounts and tightly control them if they must exist.

Local account: Used for standalone host access. The main risk is weak central control. Best controls include restricting, rotating, monitoring, and minimizing use.

Named accounts are preferred because they preserve accountability. Shared accounts are usually a bad answer unless the scenario is specifically about break-glass or emergency access. Even then, the account should be vaulted, heavily monitored, protected with strong MFA, excluded from daily use, and rotated after use.

Also know the difference between local accounts, domain accounts, and federated or cloud identities. Local accounts exist only on one system and are harder to manage centrally. Domain accounts are managed through a central directory such as Active Directory Domain Services. With federated identities, one identity provider handles the sign-in up front, and then the user can bounce across multiple services without having to log in over and over. Unmanaged local admin accounts are especially risky because they can slip past centralized policy and leave you with control that’s all over the place from one machine to the next. I’ve seen that turn into a real mess more than once. I’ve seen that turn into a mess more than once.

For non-human identities, modern environments increasingly use gMSAs in Windows, managed identities, service principals, workload identities, certificates, or short-lived tokens instead of long-lived static passwords.

4. The account lifecycle usually gets boiled down to three stages: joiner, mover, and leaver.

IAM is a lifecycle. The exam likes this because it maps directly to operational risk.

Joiner: identity proofing, approval, provisioning, group assignment, MFA enrollment.
Mover: update role, add needed access, remove old access, review for toxic combinations.
Leaver: disable account, revoke sessions and tokens, remove entitlements, preserve logs, transfer data ownership.

Identity proofing is not the same as authentication. Proofing is the process of establishing that the person is really who they claim to be before the account is ever issued. Good IAM starts with a reliable source of truth — usually HR or a student information system — along with manager approval and documented role mapping.

Provisioning is often automated in a decent environment: HR records the hire, the IAM system creates the account, drops the user into the right baseline groups, kicks off MFA enrollment, and sends approval requests for any higher-risk access. Deprovisioning has to be just as tight and disciplined — maybe even more so, because once someone leaves, you really don’t want any loose ends hanging around. In hybrid environments, disabling an on-premises directory account alone does not revoke cloud sessions, software-as-a-service refresh tokens, VPN access, or certificates.

Example hybrid offboarding workflow: 1. Receive HR termination event 2. Disable on-premises directory account 3. Disable cloud or identity provider account 4. Revoke active sessions and refresh tokens 5. Remove VPN, software service, and privileged group memberships 6. Rotate shared secrets if the user knew them 7. Transfer mailbox or files if required 8. Preserve logs and confirm completion

PowerShell note: Disable-ADAccount -Identity jsmith applies to on-premises Active Directory Domain Services and requires the Active Directory module. It does not by itself revoke software service access or cloud sessions.

Dormant and orphaned accounts should be caught automatically wherever possible. A lot of teams use a 60- to 90-day inactivity threshold and compare directory accounts against the HR system so they can spot identities that shouldn’t still be hanging around.

5. The big governance ideas here really boil down to three things: least privilege, separation of duties, and regular access reviews.

Least privilege means users get only the access needed for their current job. Need to know narrows this further for sensitive information. Separation of duties prevents one person from controlling an entire sensitive workflow. A classic example is that one person should not create a vendor, approve payment, and release funds.

Access reviews are how you keep least privilege true over time. Reviewers should check whether the access is still needed, whether the person’s role is still correct, and whether any risky or toxic access combinations have crept in. Typical review targets include privileged groups, finance access, HR systems, vendor access, and dormant accounts. The proof that the review happened matters a lot for compliance and audits.

Best answer logic: fraud or internal abuse risk points to separation of duties; too much access points to least privilege and recertification; old rights after a role change point to privilege creep.

6. The main access control models you really need to keep straight are RBAC, ABAC, DAC, and MAC — and, honestly, these four show up a lot on the exam.

RBAC assigns permissions to roles based on job function. Groups are often how RBAC gets implemented, but groups themselves aren’t the definition of RBAC. ABAC evaluates subject, object, action, and environment attributes through policy rules. DAC lets the owner decide access. MAC uses centrally enforced labels, classifications, and clearances.

RBAC: Best for enterprise job-based access. Common exam clue: access is based on department or role.

ABAC: Best for dynamic, context-aware access. Common exam clue: access is based on device, location, time, or risk.

DAC: Best for owner-controlled sharing. Common exam clue: the user decides who gets access.

MAC: Best for classified or high-security environments. Common exam clue: access depends on clearance and classification labels.

Also separate file permission inheritance from group nesting. File and folder inheritance passes permissions down an object hierarchy. Group nesting passes membership-based access through group relationships. Both can accidentally create access you didn’t mean to give if nobody reviews them.

7. Password policy, MFA, and modern authentication.

Modern guidance generally favors longer passwords or passphrases, checking against known breached passwords, secure recovery processes, and MFA. Frequent forced password rotation without a sign of compromise is usually discouraged these days, even though some compliance programs still ask for periodic changes.

Classic MFA factors are still the core three:

  • Something you know: password or PIN
  • Something you have: token, smart card, authenticator app, hardware key
  • Something you are: fingerprint or face scan

Location and behavior are often used as adaptive or risk-based signals, not always as standalone classic MFA factors. And yes, security questions are technically a knowledge factor, but they’re weak and definitely shouldn’t be trusted for strong identity verification.

Not all MFA is created equal. SMS codes and push approvals can absolutely be phished, and push prompts can also get abused through MFA fatigue attacks if an attacker keeps bothering the user long enough. That one’s ugly, and I’ve seen people get worn down by it. Phishing-resistant methods such as FIDO2 and WebAuthn security keys, smart cards, PIV or CAC, and certificate-based authentication provide stronger protection.

Lockouts can help against brute-force attacks, but if you make them too aggressive, you can basically hand attackers a denial-of-service angle. That’s a pretty nasty tradeoff if you’re not careful. Or, honestly, you’ll spend all your time chasing password spraying instead of actually reducing the risk. A lot of organizations lean on smart lockout, throttling, risk detection, and breached-password screening instead of depending on a hard lockout alone.

8. The big pieces to understand here are SSO, federation, SAML, OAuth 2.0, and OpenID Connect — and the exam loves to mix them up.

SSO means the user signs in once and can then move across multiple applications without logging in again each time. Federation is the trust relationship that lets one system accept identity information from another system. The identity provider authenticates the user; the service provider or relying party trusts the result.

SAML is commonly used for browser-based enterprise SSO and exchanges XML-based assertions. OAuth 2.0 is an authorization framework used for delegated access to resources. OpenID Connect adds authentication and identity claims on top of OAuth 2.0, usually through an ID token. That’s the exam-safe distinction: OAuth is about granting access to resources, while OIDC adds the identity layer that supports the login itself.

High-level SSO flow: User -> Identity provider authenticates user -> Identity provider issues assertion or token -> Application trusts identity provider -> Access granted

Federation works well, but it creates concentration risk. The identity provider becomes a high-value target. Misconfigured claims, stale federation trusts, weak signing certificate management, broad redirect locations, token theft, and long session lifetimes can all create exposure. Secure the identity provider, protect admin accounts with MFA, review trust metadata and certificates, and understand token revocation and session lifetime behavior.

9. Directory Services and AAA Infrastructure

Active Directory is a directory service. LDAP is a directory access protocol, not an authentication protocol by itself, although applications may use LDAP bind operations to validate credentials. Use LDAP over encrypted transport where appropriate to protect traffic.

Kerberos is a ticket-based authentication protocol used heavily in Windows domains. The user first authenticates with the KDC and receives a TGT (ticket-granting ticket). When the user accesses a service, the system requests a service ticket and uses that ticket instead of sending the user’s actual credentials again and again. Kerberos depends on accurate time sync, proper DNS, and correct SPNs, which is why clock skew comes up so often as a troubleshooting clue. It’s one of those classic gotchas that trips a lot of people up.

RADIUS is commonly used for network access AAA such as VPN, Wi-Fi, and 802.1X. Traditional RADIUS only encrypts the password field, not the entire packet. TACACS+, often associated with network device administration, encrypts the full payload, separates AAA functions more cleanly, and supports granular command authorization.

Best answer logic: VPN or wireless access usually points to RADIUS. Router, switch, or firewall admin command control usually points to TACACS+.

Group Policy matters a lot in Windows environments for enforcing password rules, lockout settings, restricted groups, and logon restrictions, but it isn’t a full IAM platform by itself.

10. Privileged, service, and break-glass accounts.

Privileged accounts need stronger controls because if they get compromised, the blast radius is much bigger. Use separate admin accounts, PAM, MFA, and ideally a Privileged Access Workstation (PAW) for administrative activity. Mature programs also use JIT access for time-limited elevation and JEA for narrowly scoped admin capability.

PAM commonly includes credential vaulting, approval workflows, brokered or proxied sessions, session recording, and audit reporting. That is how organizations move from “admins are trusted” to “privileged activity is controlled and attributable.”

Service accounts should be non-interactive whenever possible, tightly scoped, watched for unusual behavior, and tied to a documented owner. I’d rather see gMSAs, managed identities, service principals, certificates, or short-lived workload tokens than static passwords every time. Hardcoded secrets in scripts and config files are one of those recurring real-world failures that just won’t die.

Break-glass accounts are acceptable only for emergency access. They should stay out of routine use, be protected with strong compensating controls, be stored securely, be monitored closely, and get rotated right after they’re used.

11. Conditional Access, Zero Trust, and Hybrid IAM

Conditional access is a policy enforcement mechanism that evaluates context and then decides whether to allow, block, require MFA, require a compliant device, or limit a session. Common signals include user role, device compliance, location, time of day, impossible travel, sign-in risk, and application sensitivity.

This fits well with Zero Trust principles: explicit verification, least privilege, and assumed breach. A good example is allowing payroll access only from a managed device, in an approved region, with MFA, and blocking legacy authentication. In hybrid environments, also watch for gaps where software services are federated but cloud admin portals or local accounts are still using weaker direct authentication.

Roll conditional access out carefully. Use report-only or audit mode first, test exclusions for emergency accounts, and expect false positives if device posture or geolocation data is incomplete.

12. Troubleshooting and Security+ Scenario Logic

Security+ questions often test diagnosis through symptoms. Use the clue words.

Symptom: User can log in but cannot open finance share
Likely IAM area: Authorization
Best fix: Check ACLs, group membership, and role assignment

Symptom: Admin can use a software service app but not the cloud management console
Likely IAM area: Federation or MFA scope gap
Best fix: Protect the admin portal with identity provider MFA or direct MFA

Symptom: Kerberos login fails intermittently
Likely IAM area: Time synchronization, DNS, or SPN issues
Best fix: Check clock skew, service principal names, and DNS

Symptom: VPN rejects valid users
Likely IAM area: RADIUS or AAA
Best fix: Check shared secret, policy, group mapping, and logs

Symptom: Terminated user still active in cloud apps
Likely IAM area: Incomplete deprovisioning
Best fix: Disable the identity provider account and revoke sessions and tokens

For reliable accounting and auditing, log important IAM events such as failed logons, lockouts, MFA failures, privilege elevation, group membership changes, disabled-account logon attempts, impossible travel alerts, and service-account interactive logon attempts. Centralize logs in a SIEM, maintain time synchronization, and protect log integrity so the audit trail is usable.

Exam traps to avoid: SSO is not MFA. Password plus PIN is not MFA. LDAP is not the same as Kerberos. Shared access is rarely better than named accounts. Lockout is not the same as disablement. OAuth 2.0 is not the same as OIDC.

13. Final Review and Memory Aids

If you need a fast final pass for the exam, remember these:

  • Identification is the claim; authentication verifies it.
  • Authentication = who are you; authorization = what can you do; accounting = what happened.
  • Use named accounts for accountability.
  • Separate standard and privileged accounts.
  • Joiner-Mover-Leaver is the core lifecycle model.
  • Terminated user = immediate disablement and session revocation.
  • RBAC = role-based; ABAC = context and attributes; DAC = owner-controlled; MAC = labels and clearances.
  • Longer passwords, breached-password screening, and MFA beat complexity-only thinking.
  • Phishing-resistant MFA is stronger than SMS or basic push.
  • SAML = enterprise browser SSO assertions.
  • OAuth 2.0 = delegated authorization.
  • OIDC = authentication layer on OAuth.
  • LDAP = directory access; Kerberos = ticket-based authentication.
  • RADIUS = network access AAA; TACACS+ = device admin AAA.
  • PAM, JIT, JEA, and PAWs protect privileged access.

Best-answer mindset: the strongest Security+ choice usually improves least privilege, accountability, and lifecycle control at the same time.