CompTIA SY0-701: Identity and Access Control
Identity and access control is the process of proving who or what a subject is, deciding what that subject is allowed to do, and maintaining those decisions across its lifecycle. CompTIA Security+ SY0-701 places identity and access management in Security Operations and expects candidates to understand provisioning and deprovisioning, permissions, identity proofing, federation, single sign-on, access-control models, multifactor authentication, password concepts, and privileged access management.
Those topics form one operational chain. Weak identity proofing can enroll the wrong person, poor provisioning can grant excessive access, missing deprovisioning can leave former staff active, weak authentication can expose valid accounts, and broad authorization can turn one compromised credential into a large incident. Access control is therefore a system, not one login screen.
Identity operations belong inside CompTIA Security Operations.
Provision identities from authoritative evidence
Identity proofing confirms that a person or entity is who it claims to be before an account receives access.
Provisioning should start from an authoritative HR, customer, device, or workload source and assign only the access required for the initial role.
Identity lifecycle is strongest when joiners, movers, and leavers flow through one controlled process.
Deprovision quickly
Access should be removed when employment ends, a contract expires, a device is retired, or a workload is decommissioned.
Deprovisioning includes sessions, tokens, API keys, group membership, privileged accounts, remote access, and application-specific entitlements.
An account disabled in one directory is not fully deprovisioned if SaaS sessions or local privileged accounts remain active.
Separate authentication from authorization
Authentication proves identity; authorization determines allowed actions after authentication.
Zero Trust reinforces the idea that a valid sign-in does not grant universal trust.
Authorization should consider role, attributes, resource sensitivity, device or session context, and least privilege according to the system’s risk model.
Use MFA that resists common attacks
Multifactor authentication combines independent factor types such as something you know, have, or are.
MFA design should protect privileged and high-risk access especially strongly.
Phishing-resistant authenticators are preferable for sensitive administration because not every second factor provides the same resistance to adversary-in-the-middle or push-fatigue attacks.
Use federation and SSO carefully
Federation lets one identity provider assert user identity to another service, while SSO reduces repeated authentication across applications.
Federated identity can simplify lifecycle and strengthen centralized authentication, but it also makes the identity provider a critical dependency.
Common protocols such as SAML and OpenID Connect solve interoperability; application authorization still remains local to the service.
Choose an access-control model
Role-based access control groups permissions by job role; attribute-based access control evaluates subject, resource, action, and environment attributes.
Discretionary and mandatory access-control models express different ownership and classification rules.
The model should fit the system instead of forcing every application into one enterprise abstraction.
Apply least privilege and separation of duties
Users and workloads should receive only the permissions needed for their tasks and only for as long as required.
Separation of duties prevents one person from controlling every stage of a sensitive transaction or security process.
Privileged access can use just-in-time activation, approval, time limits, and audit to reduce standing administrator privilege.
Use PAM for privileged credentials and sessions
Privileged access management can vault credentials, rotate passwords, broker privileged sessions, enforce approval, and record administrative activity according to platform capability.
Shared administrator passwords should be eliminated or tightly controlled because they weaken attribution and lifecycle.
PAM complements normal IAM by adding stronger controls around the identities whose actions have the greatest consequence.
Review access continuously
Attestation and access reviews confirm that current permissions still match the user’s role and business need.
For Security+ SY0-701, the durable identity lifecycle is proof → provision → authenticate → authorize → elevate only when required → review → deprovision.
Access control works when identity, permissions, authentication, federation, and privileged operations remain synchronized as people, devices, and workloads change.
Identity proofing is strongest before the first credential is issued. Organizations may validate government-issued identity, HR records, customer evidence, device ownership, or another trusted source depending on the system. Weak proofing cannot be repaired by strong MFA later if the organization enrolled the wrong person in the first place.
Provisioning should reflect role and minimum need. New employees should not inherit every permission their predecessor accumulated over years. Start from job-function baselines and add exceptions intentionally. Automated lifecycle systems reduce delay and human error, but the authoritative source must remain accurate or automation simply distributes bad access faster.
Mover events are as important as joiners and leavers. Promotions, department transfers, project changes, leaves of absence, and contractor conversions can all require access removal as well as new grants. Role changes should trigger reevaluation rather than only additive permission updates.
Authorization models have different strengths. RBAC simplifies common job-function access; ABAC can scale dynamic decisions across resource tags and user attributes; DAC gives resource owners discretion; MAC relies on centrally enforced classifications. Security+ candidates should be able to compare the concepts rather than assume one model is always superior.
Time-of-day, location, device posture, risk, and other context can supplement authorization in modern systems. These conditions should narrow or step up access without becoming hidden rules users cannot understand. High-risk exceptions should create logs and reviewable decisions.
MFA factors must be independent enough that compromise of one does not automatically defeat the other. A password plus another password is not multifactor. Hardware-backed passkeys, smart cards, or FIDO authenticators can provide stronger phishing resistance than SMS or push prompts for administrator access, while usability and recovery still need planning.
Password controls should emphasize long, unique credentials, protected storage, resistance to common/breached passwords, and secure reset. Arbitrary frequent password changes can lead users toward predictable patterns unless an actual compromise or policy requirement justifies rotation. Password managers can help users maintain unique secrets across services.
Account recovery is part of authentication security. Help-desk reset procedures can bypass MFA if an attacker can socially engineer identity verification. Recovery should use strong proofing, separation of duties for privileged accounts, and audit trails that show who changed credentials or factors.
Single sign-on reduces credential sprawl but increases dependency on the identity provider. Resilience planning should cover IdP outage, token signing keys, federation certificates, DNS, and network dependencies. Critical systems may need documented break-glass access that is protected separately from routine SSO.
Federation protocols have different roles. SAML is common for enterprise browser SSO, OAuth 2.0 is an authorization framework used for delegated API access, and OpenID Connect adds an identity layer on OAuth. Candidates should keep authentication, authorization, and token delegation concepts distinct.
Interoperability matters because an enterprise can contain Active Directory, cloud IdPs, SaaS apps, VPNs, Linux systems, APIs, and privileged platforms. Federation and provisioning standards reduce local accounts, but each system still needs correct authorization mapping and timely deprovisioning.
Privileged accounts deserve separate identities where practical. Administrators should not browse email and the web with the same high-privilege session used to manage critical infrastructure. Separate admin personas, just-in-time elevation, session recording, and approval reduce exposure and improve attribution.
PAM can also manage nonhuman privileged credentials. Service accounts, database administrators, network devices, API keys, and automation secrets often outlive individual employees and can become poorly owned. Vaulting, rotation, and session brokering can bring them into the same controlled lifecycle.
Access attestation should be risk-based. Review privileged roles, sensitive data access, dormant accounts, third-party access, and segregation-of-duties conflicts more frequently than low-risk read-only entitlements. Reviewers need enough business context to decide whether access is still necessary rather than simply clicking “approve all.”
Identity monitoring completes the lifecycle. Authentication failures, impossible travel, repeated MFA prompts, dormant account use, privilege changes, new federation trust, and deprovisioning failures can all be security signals. Access control is strongest when operations can detect that the identity system itself is behaving abnormally.
For Security+ study and real operations, think AAA plus lifecycle: identify/proof, authenticate, authorize, account for activity, review, and remove access. Every control—MFA, SSO, RBAC, PAM, federation, passwords—fits somewhere in that sequence and should be evaluated by the risk it reduces.
Service accounts and machine identities should follow the same least-privilege lifecycle as humans. They need an owner, purpose, credential or federation mechanism, allowed resources, rotation or short-lived token strategy, and retirement date. Nonhuman accounts are often riskier because nobody notices when they remain active after the application that created them is gone.
Authorization logging supports accountability. Systems should record the identity, resource, action, result, privilege level, and relevant session context for sensitive operations. Those records make access reviews and incident response more reliable than relying on memory of who “normally” administers a system.
Access-control design should also include failure behavior. If the identity provider is unavailable, decide which systems fail closed, which have controlled offline/emergency access, and how that emergency use is audited. Resilience should not mean bypassing authentication completely during an outage.
Review identity architecture after mergers, application migrations, new federation providers, or major role changes. Access models become dangerous when the directory, business organization, and actual permissions drift apart while old groups and privileged assignments remain active.
Keep access ownership explicit.
Review.