Identity and Access Management for CompTIA Security+ SY0-701: Concepts, Scenarios, and Study Priorities

 

Identity and access management is one of the most important ideas running through CompTIA Security+ SY0-701. It appears directly in Security Operations, but it also connects to Zero Trust, cloud architecture, incident response, governance, risk, authentication, authorization, and data protection. A security program can deploy strong network controls and hardened systems, yet a compromised or overprivileged identity may still give an attacker a legitimate path to sensitive resources.

For Security+ preparation, identity should therefore be studied as a lifecycle and decision system rather than a collection of authentication acronyms. You need to understand how identities are established, how accounts are provisioned, how authentication works, how authorization is assigned, how access is reviewed, how privileged users are controlled, how federation and single sign-on change trust, and how access is removed when it is no longer required.

The Security+ guide provides the broader exam context, while the SY0-701 objectives explains how IAM fits into the complete objective set. This article focuses on turning identity concepts into scenario-ready understanding.

Begin with the identity lifecycle

A useful IAM model follows an identity from creation to retirement:

1. Establish that the person, device, service, or workload is who it claims to be.
2. Create or provision the account or identity record.
3. Assign appropriate access based on role, attributes, rules, or policy.
4. Authenticate the identity when it requests access.
5. Authorize specific actions after authentication.
6. Monitor activity and review whether access is still appropriate.
7. Change permissions when responsibilities change.
8. Remove access promptly when the identity no longer needs it.

Many Security+ scenarios are simply one stage of this lifecycle described in operational terms.

A new employee needs access to several applications. That is provisioning and authorization. An employee moves from finance to engineering. That is an access-review and modification problem. A contractor’s engagement ends. That is deprovisioning. An administrator needs elevated access for thirty minutes. That is privileged access management and just-in-time authorization. A cloud application needs to trust an external identity provider. That is federation.

If you can identify the lifecycle stage, the answer choices become much easier to evaluate.

Authentication, authorization, and accounting are different controls

Candidates often know the AAA acronym but still blur the functions in scenarios.

Authentication answers: who are you, or what system are you?

Authorization answers: what are you allowed to do?

Accounting or auditing answers: what activity occurred, and can it be attributed and reviewed?

A user can authenticate successfully and still be denied access because authorization does not permit the requested action. A user can also authenticate successfully and have far too much access because authorization is poorly designed. Logging and auditing then provide evidence of how the account was used.

The distinction matters because the best control depends on the problem. If attackers are signing in with stolen passwords, stronger authentication may be needed. If legitimate users can read data outside their responsibilities, the issue is authorization. If investigators cannot determine what a privileged user changed, the weakness may be logging and accountability.

The fundamentals practice is useful when you want to reinforce these foundations before working through more complex IAM scenarios.

Identity proofing: authentication begins before the first login

Identity proofing is the process of establishing confidence that an identity belongs to the person or entity being enrolled. It happens before ordinary authentication can be trusted.

If an attacker can fraudulently create or take ownership of an account during enrollment or recovery, strong authentication after that point may protect the wrong person.

Identity proofing can involve documents, trusted records, in-person verification, existing organizational relationships, or other evidence depending on risk. Security+ does not require you to design a national identity system, but it does expect you to understand the principle: authentication strength is limited by enrollment strength.

Password-reset and account-recovery processes deserve the same attention. A highly secure login process can be undermined by weak recovery questions or poorly verified help-desk requests.

Provisioning: give access deliberately

Provisioning creates identities and grants initial access. Good provisioning is based on approved roles, business need, least privilege, and documented ownership rather than on copying whatever permissions another employee happens to have.

A strong process answers:

• Who requested the account?
• Who approved access?
• Which role or attributes justify the permissions?
• Does the user need privileged access?
• When should access begin?
• Is the access temporary or permanent?
• Which systems should receive the identity?
• How will access be reviewed later?

Automation can make provisioning faster and more consistent, but automation should reproduce an approved policy rather than automate excessive access.

This connects directly to the Security Operations, because identity provisioning and deprovisioning are ongoing operational responsibilities.

Deprovisioning: remove access completely and promptly

Deprovisioning is one of the clearest examples of why identity is a lifecycle. When an employee leaves, contractor access expires, service account is retired, or application integration is removed, access should not remain indefinitely.

Good deprovisioning can include disabling or deleting accounts, revoking sessions and tokens, recovering devices, rotating shared secrets, removing group memberships, revoking certificates or keys, transferring ownership, and documenting the change.

The exact actions depend on the identity type. A human employee, service account, API integration, and cloud workload may require different offboarding steps.

Security+ scenarios may emphasize speed. A terminated employee with active privileged access is an immediate risk. In that case, disabling access can be more important than completing every administrative cleanup task first.

Least privilege: minimize what an identity can do

Least privilege means providing only the permissions needed for the required task and no more. It reduces the impact of mistakes, compromised accounts, malicious insiders, and software vulnerabilities.

Least privilege is not the same as “no access.” Security still has to support business function. The goal is appropriate access.

A useful exam question is: What is the smallest permission set that allows the required activity?

If a help-desk technician only needs to reset passwords for ordinary users, broad domain-administrator privileges are excessive. If an application only needs read access to one database table, write access to the entire database is unnecessary. If a vendor needs temporary maintenance access, permanent unrestricted connectivity creates avoidable risk.

Least privilege also works best with periodic review because appropriate access today can become excessive after a job change.

Access-control models: learn the decision logic

SY0-701 includes mandatory, discretionary, role-based, rule-based, attribute-based, time-based, and least-privilege concepts. Memorizing labels is less useful than understanding who or what makes the authorization decision.

Role-based access control

Role-based access control assigns permissions to job roles and then assigns users to roles. It works well when many people perform predictable job functions.

The advantage is consistency. Instead of manually assigning dozens of permissions to each new analyst, the organization can assign an analyst role.

The risk is role sprawl or overbroad roles. If roles are never reviewed, users may accumulate unnecessary access through job changes.

Attribute-based access control

Attribute-based access control uses attributes about the user, resource, environment, device, or request to make access decisions. Examples might include department, device compliance, data sensitivity, location, or time.

This can support dynamic policies but requires accurate attributes and carefully designed logic.

Rule-based access control

Rule-based access uses defined conditions or rules. Network access controls and firewall-style policies often use rule logic. The distinction from role-based control is that the decision is based on rules rather than primarily on the user’s organizational role.

Discretionary access control

In discretionary models, resource owners can often decide who gets access to their objects. This offers flexibility but can make organization-wide consistency more difficult.

Mandatory access control

Mandatory access control uses centrally enforced labels, classifications, or security rules that ordinary resource owners cannot simply override. It is associated with environments that require strict control over how subjects and objects interact.

Time-of-day and contextual restrictions

Access can also be limited based on time, location, device state, risk, or other context. These restrictions illustrate an important Zero Trust idea: authorization can depend on current conditions rather than on a one-time decision.

Multifactor authentication: factors, not steps

MFA requires more than one independent factor category. Common factor categories include something you know, something you have, something you are, and in some models somewhere you are.

Two passwords are not two factors because both are knowledge. A password plus a security key combines knowledge and possession. A security key plus biometric verification combines possession and inherence.

Candidates should distinguish a factor from an implementation. Biometrics, hardware or software tokens, security keys, one-time codes, push approvals, and certificates may all participate in authentication designs, but the security strength depends on how they are used.

MFA reduces the value of a stolen password, but it is not invulnerable. Social engineering, session theft, weak recovery, approval fatigue, and compromised endpoints can still create risk. Phishing-resistant methods can provide stronger protection than authentication flows that depend on easily relayed codes or prompts.

The correct exam answer depends on the stated threat and requirement rather than the generic statement that “MFA is good.”

Password concepts: focus on usability and attack resistance

Security+ includes password length, complexity, reuse, expiration, age, password managers, and passwordless approaches.

Longer passwords generally increase resistance to guessing, especially when they are unique. Complexity rules can add variation but may produce predictable user behavior if they become overly rigid. Reuse is dangerous because compromise at one service can expose another. Forced expiration can create weak patterns if users make trivial changes, while password changes remain important when compromise is suspected.

Password managers help users generate and store unique credentials rather than reusing memorable passwords across services.

Passwordless approaches reduce dependence on shared secrets and can improve both security and usability when implemented with strong cryptographic authenticators and secure enrollment.

For the exam, avoid turning password guidance into one universal numeric rule. Read the scenario and identify which weakness is being addressed.

Single sign-on: one authentication experience across multiple resources

Single sign-on allows a user to authenticate once and access multiple connected resources without entering credentials separately for every application.

SSO can improve usability and reduce password sprawl. It can also centralize authentication policy and visibility. However, the identity provider becomes highly important. If the central identity is compromised, multiple applications may become accessible.

The security implication is concentration of trust. Strong authentication, resilient identity infrastructure, session controls, logging, and least privilege become especially important.

Federation: trust across identity domains

Federation allows separate organizations, domains, or services to trust identity assertions without requiring each application to maintain an independent credential for the user.

For example, a company may allow employees to use the corporate identity provider to access a third-party application. The third party trusts an assertion from the identity provider rather than storing the employee’s corporate password.

The central exam concept is delegated trust. Who authenticates the user? Who consumes the assertion or token? What information is passed? What happens if the identity provider or trust configuration is compromised?

Federation and SSO often appear together, but they are not identical. SSO describes the user experience of authenticating once for multiple services. Federation describes trust and identity exchange across security domains.

SAML: assertions for federated identity

SAML is commonly associated with enterprise web SSO and federated authentication. An identity provider can issue a signed assertion containing information about an authenticated user, and a service provider can rely on that assertion according to an established trust relationship.

At Security+ level, focus on roles and trust rather than XML details. Know that the identity provider authenticates, the service provider consumes the assertion, and signatures help protect integrity and trust.

If a scenario describes employees using corporate credentials to access an external enterprise SaaS application through browser-based SSO, SAML may be a relevant concept.

OAuth: delegated authorization

OAuth is primarily an authorization framework. It allows a user to grant an application limited access to another service without giving the application the user’s password for that service.

This distinction is important: OAuth is not simply “another login protocol.” It is about delegated access.

A common mental model is: a user authorizes one application to perform specific actions against another service. Tokens represent that authorization, and scopes can limit what the application may do.

Do not confuse authorization delegation with proving the user’s identity. Authentication can be layered through related technologies, but the Security+ concept to remember is OAuth’s role in delegated authorization.

LDAP: directory access rather than internet federation

LDAP is used to query and interact with directory services that store information about users, groups, systems, and other objects. It can support authentication and directory lookups in enterprise environments.

Security+ scenarios may place LDAP alongside SAML or OAuth, so identify the context. If the question is about a directory of organizational users and groups, LDAP may fit. If it is about browser-based federation to a cloud service, SAML may be more likely. If it is about granting an application limited access to another service, OAuth may be relevant.

The point is not to memorize acronyms separately. It is to match the protocol to the trust problem.

Do not collapse identity protocols into one “SSO” bucket

Several identity technologies can appear in the same environment, but they solve different problems. LDAP is primarily a directory-access protocol. SAML is commonly used to exchange authentication and authorization assertions between an identity provider and a service provider. OAuth is designed for delegated authorization: it allows a client to obtain scoped access to a resource without receiving the user’s password. Single sign-on describes a user experience and authentication pattern; federation describes trust between identity domains.

Those distinctions matter because a scenario may contain several true statements and still have one best answer. If the requirement is “let employees use the corporate identity provider to access a separate SaaS application,” federation and an assertion-based flow may be central. If the requirement is “allow an application to call an API on the user’s behalf with limited scope,” delegated authorization is the key idea. If the requirement is “query organizational directory information,” a directory protocol belongs in the discussion.

The safest study method is to write a one-sentence purpose for each technology and then a sentence describing what it does not solve. That prevents acronym recognition from replacing architectural understanding.

Identity interoperability and attestation

Interoperability allows identity systems to work across platforms, applications, and organizational boundaries. Without compatible formats, protocols, and trust models, every application becomes an isolated identity silo.

Attestation provides evidence or confirmation that a claim, device state, identity, or access condition can be trusted according to policy. In IAM scenarios, think of attestation as part of establishing confidence rather than merely storing an identity record.

These concepts become particularly important in cloud and Zero Trust environments where access decisions depend on multiple sources of context.

Privileged access management: administrators need different treatment

Privileged accounts can make high-impact changes, access sensitive systems, alter security controls, and create or remove other identities. They therefore deserve stronger protection than ordinary user accounts.

Privileged access management can include password vaulting, temporary elevation, session monitoring, approval workflows, separate administrative accounts, and just-in-time permissions.

Just-in-time permissions

Just-in-time access grants privilege only when needed and removes it afterward. This reduces the period during which a compromised account has administrative capability.

Password vaulting

A vault protects privileged credentials, controls retrieval, rotates secrets, and can improve accountability. It is especially useful when legacy systems still depend on passwords or shared administrative credentials.

Ephemeral credentials

Short-lived credentials reduce the value of stolen secrets because they expire quickly. They also discourage permanent high-value credentials from being distributed widely.

The guiding idea is to reduce standing privilege. An account that is always an administrator creates more continuous risk than one that receives controlled elevation for a specific task.

Service accounts and non-human identities

Not every identity belongs to a person. Applications, services, scripts, devices, containers, and workloads may need credentials or identities to access resources.

These accounts are easy to neglect because they do not complain when a password expires and may not have a human owner checking their permissions.

Secure management includes clear ownership, least privilege, credential rotation, avoidance of hard-coded secrets, monitoring, lifecycle management, and removal when the service is retired.

A forgotten service account with broad privilege can remain active for years and become an attractive attack path.

Permissions: think in effective access

A user may receive permissions directly, through groups, through roles, from inherited policy, or through several overlapping mechanisms. What matters operationally is the effective result.

Scenario questions may describe a user who should not have access but still does. The correct approach is to trace where the permission originates rather than removing random assignments.

This is also why group and role design matters. Clean role-based access is easier to review than hundreds of individual exceptions.

Separation of duties and dual control

Although IAM often focuses on least privilege, organizations may also divide sensitive workflows so one person cannot perform an entire high-risk action alone.

For example, one employee may request a financial change while another approves it. One administrator may prepare a deployment while another authorizes production release. This reduces fraud and error by preventing excessive concentration of capability.

If a scenario is concerned with one person having end-to-end power over a critical process, separation of duties may be more appropriate than simply adding another authentication factor.

Zero Trust changes how access decisions are viewed

Traditional models often treated the internal network as more trustworthy than the external internet. Zero Trust reduces implicit trust and emphasizes explicit verification, least privilege, policy-driven decisions, and continuous evaluation.

In identity terms, that can mean combining user identity, device condition, location, risk signals, resource sensitivity, and session context before granting access.

Authentication is no longer the end of the decision. A user can be re-evaluated as conditions change.

This is why IAM and architecture are closely related. In distributed and cloud environments, identity increasingly becomes a major control plane.

IAM and incident response

Identity evidence is often central to investigations. Failed logins, successful sign-ins, impossible travel, new MFA registrations, password resets, token issuance, privilege changes, new group membership, application consent, and session activity can all help investigators understand what happened.

When an account is suspected of compromise, the response may include disabling the account, revoking sessions, resetting credentials, removing unauthorized MFA methods, reviewing privileges, checking related identities, examining endpoint activity, and searching for persistence.

The important point is that changing a password may not be enough if active sessions or tokens remain valid.

This connects IAM directly to the Security Operations.

IAM and governance

Access policies are not created by administrators alone. Governance determines acceptable access models, approval requirements, review frequency, separation of duties, third-party access, privileged account requirements, and retention of audit evidence.

A technically functional permission can still violate policy or regulation.

Security+ candidates should therefore connect access control to business ownership. System owners, data owners, managers, security teams, HR, and compliance functions may all participate in deciding who should have access and when.

Identity case study: the joiner, mover, leaver lifecycle

Consider an engineer who joins a company, transfers into a cloud-administration team six months later, then leaves for another employer.

At onboarding, identity proofing establishes that the account belongs to the right person. Provisioning creates the account and assigns baseline access. The initial role should provide only what the engineer needs for the first job. Multifactor authentication strengthens the authentication event, but it does not determine what the user should be allowed to do.

When the engineer moves teams, simply adding administrator access can create privilege accumulation. Good lifecycle management removes access that is no longer needed, adds the new role deliberately, records approvals, and may require stronger controls for privileged actions. Just-in-time elevation, privileged access management, separate administrative accounts, or credential vaulting can reduce standing privilege depending on the environment.

At departure, disabling the interactive account is only part of deprovisioning. Active sessions, API tokens, application passwords, shared credentials, group memberships, owned resources, delegated permissions, and service-account relationships may also matter. The organization should preserve required data and records while removing the former employee’s ability to authenticate or exercise authority.

This one lifecycle exposes the difference between identity, authentication, authorization, privilege, governance, and session control. If you can reason through it, IAM questions become much easier to untangle.

Common IAM scenario patterns

New employee

Think provisioning, identity proofing, approved role membership, least privilege, MFA enrollment, and documentation.

Employee changes roles

Think access review, removal of old privileges, assignment of new role permissions, and prevention of privilege accumulation.

Employee leaves

Think immediate deprovisioning, session revocation, token or certificate handling, device return, ownership transfer, and removal from groups and applications.

Contractor needs temporary administration

Think time-limited access, just-in-time elevation, strong authentication, restricted scope, logging, and automatic expiration.

External SaaS needs corporate login

Think federation, identity provider trust, SSO, assertions or tokens, and lifecycle integration.

User has access they should not have

Think authorization source, group membership, inherited permissions, role design, and review—not necessarily authentication.

Password was stolen

Think MFA, password reset, session revocation, detection, credential-reuse exposure, and investigation of how the theft occurred.

Privileged credential is shared

Think individual accountability, vaulting, controlled elevation, credential rotation, and elimination of persistent shared secrets where feasible.

How to distinguish common identity answers

When several IAM controls appear in the answer choices, ask what layer the problem belongs to.

• Identity proofing: Are we sure the identity was enrolled correctly?
• Authentication: Can the person prove who they are?
• MFA: Does authentication rely on independent factors?
• Authorization: What is the identity allowed to do?
• RBAC/ABAC: How are authorization decisions organized?
• Federation: How do separate identity domains trust one another?
• SSO: Can one authenticated session provide access to multiple services?
• PAM: How are high-risk privileges controlled?
• Deprovisioning: How is access removed?
• Accounting/auditing: Can activity be attributed and reviewed?

This simple classification eliminates many distractors.

Common IAM study mistakes

Memorizing SAML, OAuth, and LDAP as equivalent protocols

They solve different identity and access problems. Learn the scenario each one supports.

Thinking MFA fixes authorization

MFA can make authentication stronger. It does not correct excessive permissions.

Forgetting account lifecycle

The security of an account is not only about login. Provisioning, changes, review, and removal are equally important.

Treating administrators like ordinary users

Privileged accounts need stronger control because compromise has greater impact.

Ignoring service accounts

Non-human identities can have powerful, long-lived access and require ownership and lifecycle management.

Confusing SSO with federation

SSO describes a user experience; federation describes trust across identity domains. They can appear together without being the same concept.

A practical IAM lab without a complex enterprise environment

You can learn IAM principles with a small lab or even a paper design.

Create five fictional roles: ordinary employee, help-desk technician, security analyst, application owner, and administrator. Give each role a set of resources and required tasks. Then design access using least privilege.

Next, create a new employee and provision the account. Move the employee to a new role and revise permissions. Create a contractor who needs one week of elevated access. Add a cloud application that uses corporate SSO. Finally, terminate an employee and write the deprovisioning checklist.

For every step, ask:

• Who approves the access?
• Which control authenticates the identity?
• Which role or attribute authorizes the action?
• How is activity logged?
• When will the permission be reviewed?
• What removes access automatically?

This exercise turns IAM into an operational system.

Use practice questions to diagnose the type of IAM gap

When you miss an IAM question, do not record only the acronym you forgot. Classify the error.

Was it an authentication-versus-authorization problem? A protocol-selection problem? A lifecycle problem? An access-model problem? A privileged-access problem? A factor-classification problem? A federation trust problem?

The IAM practice is most useful when you use mistakes this way.

You can also return to the practice strategy when you want a systematic remediation process across all five domains.

Study priorities for IAM

Before considering the topic exam-ready, make sure you can:

• distinguish authentication, authorization, and accounting;
• explain identity proofing and why recovery processes matter;
• describe provisioning, role changes, access reviews, and deprovisioning;
• apply least privilege to human and non-human identities;
• compare role-based, attribute-based, rule-based, discretionary, and mandatory access models;
• distinguish factor categories from authentication implementations;
• explain SSO and federation without treating them as identical;
• distinguish SAML, OAuth, and LDAP by purpose;
• explain privileged access management, just-in-time permissions, vaulting, and ephemeral credentials;
• recognize identity evidence during an incident;
• connect IAM to Zero Trust, governance, and cloud architecture.

If any one of these areas is difficult, build a scenario around it rather than memorizing another definition.

The strongest IAM answers follow the lifecycle

When an identity question feels complicated, locate the problem in the lifecycle: proofing, provisioning, authentication, authorization, privileged use, review, or deprovisioning. Then identify whether the control must prove identity, reduce privilege, govern trust, limit a session, or remove access. That is more reliable than choosing whichever authentication technology sounds strongest.