CompTIA SY0-701: Identity and Access Management

Identity and access management appears throughout Security+ because modern security depends less on a trusted network boundary and more on deciding who or what may access a specific resource under specific conditions. SY0-701 expects candidates to understand authentication, authorization, federation, privileged access, account management, access-control models, and security principles such as least privilege and zero trust.

The current SY0-701 exam remains CompTIA’s live Security+ version as of October 3, 2026. IAM questions rarely reward pure vocabulary memorization. They are usually easier when you identify the stage of the access decision: establish identity, prove identity, evaluate context, grant permissions, monitor activity, and remove access when it is no longer justified.

A good study method is to build small identity stories. Start with a new employee, give the person appropriate access, add MFA, change the job, grant temporary privilege, connect to a federated application, detect suspicious sign-in activity, and finally offboard the account. That lifecycle connects many separate objectives into one operational picture.

Authentication proves identity; authorization limits action

Security+ questions often include both concepts in the same scenario. Authentication answers “who are you?” through factors such as passwords, tokens, certificates, biometrics, or possession of a device. Authorization answers “what may you do?” through permissions, roles, policies, and access-control decisions.

Reviewing authentication protocols helps you separate identity proof from later access decisions. A user can authenticate successfully and still receive an authorization failure. Conversely, a badly designed application might grant excessive access after a valid login because its authorization model is too broad.

In practice questions, look for the failure point. “Cannot sign in” suggests authentication or account state. “Can sign in but cannot open the resource” suggests authorization. “Can open more than required” suggests excessive privilege. This classification often eliminates several distractors before you need to remember a specific protocol.

MFA is strongest when factors are genuinely independent

Multifactor authentication requires factors from different categories, commonly something you know, something you have, and something you are. Two passwords are not two factors. A password and a PIN are still both knowledge factors. Security+ expects you to recognize the difference between multiple steps and true multifactor authentication.

Also think about attack resistance rather than only the number of factors. An MFA method that can be easily phished or approved through push fatigue may be weaker than a phishing-resistant hardware or certificate-backed method. The right control depends on the risk and the capabilities of the environment.

Use IAM scenarios to connect authentication strength with privilege. An ordinary user accessing a low-risk internal application may require one control set, while an administrator changing security policy should face stronger authentication, shorter sessions, and more monitoring. Security design should become stricter as the consequence of compromise increases.

SSO and federation reduce friction but expand the trust relationship

Single sign-on lets a user authenticate once and access multiple applications, while federation allows separate identity domains to establish trust and exchange identity assertions. These designs improve usability and centralized control, but they also make the identity provider a critical security dependency.

Study single sign-on alongside federation concepts such as SAML, OAuth, and OpenID Connect. Do not reduce them to “protocols for login.” They carry different information and solve different problems involving authentication, authorization delegation, and identity claims.

A Security+ scenario may ask which approach reduces password sprawl, enables a partner organization to use its own identities, or allows an application to obtain limited access to another service without receiving the user’s password. Identify the trust problem first, then choose the protocol or architecture that fits it.

Least privilege applies to users, administrators, services, and applications

Least privilege means giving an identity only the permissions required for the task and only for as long as necessary. It applies to human accounts and to service accounts, APIs, automation, cloud workloads, and third-party integrations. Excessive privilege increases blast radius when an identity is compromised.

Use access control models to understand how organizations structure authorization, then add modern operational controls such as role-based access, privileged access management, and just-in-time elevation. The model establishes how permissions are organized; operational controls determine how access is granted and reviewed.

In labs, create two roles that are intentionally similar and test what each can do. Remove one permission and observe the failure. This is more useful than memorizing “least privilege is good” because it teaches how permissions map to actual actions.

Zero trust changes how identity is evaluated over time

Traditional access decisions often treated successful login from an internal network as sufficient trust. Zero-trust designs continuously consider identity, device posture, location, sensitivity, behavior, and other context. The principle is to verify explicitly, minimize privilege, and assume that compromise is possible.

The concepts behind zero trust are valuable for Security+ because they connect IAM to network and endpoint security. A user’s identity may be valid while the device is unmanaged or the request originates from an unusual location. Access decisions can account for more than one signal.

Do not interpret zero trust as “block everything.” The goal is risk-aware access with strong verification and limited blast radius. A well-designed system can improve user experience through SSO and passwordless methods while simultaneously enforcing stronger contextual controls.

Certificates and PKI support machine and user identity

Passwords are only one way to establish identity. Certificates can authenticate users, devices, servers, applications, and network connections. Security+ candidates should understand certificate authorities, trust chains, revocation, key pairs, and common certificate use cases without needing to become PKI engineers.

Use PKI and digital certificates to connect cryptography with IAM. A certificate proves possession of a private key associated with an identity, while the certificate authority and trust chain help relying parties decide whether that identity claim should be trusted.

Scenario questions often reveal the use case through the asset: a web server needs TLS, a managed device needs certificate-based authentication, or an enterprise needs scalable trust without distributing shared secrets. Recognizing the identity being authenticated makes the certificate decision much easier.

Account lifecycle failures create predictable security gaps

Identity security is not only about login technology. Accounts must be provisioned correctly, changed when responsibilities change, reviewed periodically, disabled promptly at departure, and monitored for suspicious behavior. Orphaned accounts and stale privilege can survive for years if lifecycle processes are weak.

Practice “joiner, mover, leaver” scenarios. A new employee receives baseline access through group membership. A promotion requires a new role but should remove incompatible permissions. A contractor receives time-limited access. A departing user is disabled and active sessions or tokens are revoked.

Then add privileged accounts and service accounts. These identities may not follow the same human-resources triggers as ordinary users, which makes ownership and periodic review even more important. Security+ frequently rewards the control that reduces long-lived unnecessary access rather than the control that merely makes authentication more complicated.

Study IAM as a sequence of security decisions

For final review, take every IAM question and map it to a sequence: identify the subject, authenticate it, evaluate context, authorize the action, record the event, review the access, and revoke it when no longer needed. This prevents related terms from blurring together under exam pressure.

If the scenario involves centralized identity, think about centralized access control and the benefits of consistent policy and logging. If the scenario involves remote or federated access, focus on trust boundaries and protocol behavior. If the scenario involves privilege, focus on least privilege, separation of duties, and temporary elevation.

IAM matters in SY0-701 because identity has become a primary security boundary across cloud, SaaS, remote work, APIs, and traditional infrastructure. Candidates who understand the full decision chain can solve identity questions with reasoning instead of memorization—and that same reasoning transfers directly to real security work.

Privileged access management deserves special attention because administrator compromise can bypass many other controls. Separate ordinary and administrative accounts where appropriate, require stronger authentication for privileged actions, limit elevation duration, monitor sensitive changes, and avoid shared administrator credentials that destroy accountability.

Service accounts and workload identities create a different problem. They may run continuously, cannot respond to an MFA prompt like a human, and are often forgotten after the application is deployed. Give them narrowly defined permissions, protect their credentials or use managed identity mechanisms where available, document ownership, and rotate or retire credentials when systems change.

Identity logs are also security evidence. Repeated failed logins, new MFA enrollment, unusual source locations, impossible travel, privilege changes, dormant-account use, and suspicious token behavior can all contribute to detection. Security+ does not require you to become a full-time identity threat analyst, but you should understand why authentication events matter to incident response.

For exam practice, take one IAM control and ask what attack it reduces, what legitimate activity it could disrupt, and what evidence would show that it is working. That three-part test turns abstract controls into security decisions. It also makes distractors easier to reject because you can evaluate whether the proposed control actually addresses the stated risk.

When several IAM answers look plausible, return to the business requirement. If the priority is reducing password reuse, SSO or federation may help. If the priority is reducing impact from a compromised administrator, least privilege and privileged-access controls matter more. If the priority is proving device identity, certificates may be the better fit. The requirement should choose the control, not the familiarity of the acronym.

• Category: All Certifications Certifications