Identity and access management answers a deceptively simple set of questions: who or what is requesting access, how is that identity verified, what is it allowed to do, and how long should that access remain valid? Within Identity & Access Management Fundamentals, the current CompTIA Security+ SY0-701<\/a> objectives treat IAM as a foundation because modern security depends on identity across endpoints, cloud platforms, SaaS applications, APIs, service accounts, and administrative tools. Network location alone is no longer enough to establish trust.<\/p>\n IAM is more than login technology. It includes identity lifecycle, authentication, authorization, federation, privileged access, access reviews, service identities, logging, and policy enforcement. A strong program removes access when roles change, requires stronger proof for higher-risk actions, avoids shared accounts, and records enough context to investigate suspicious behavior. A weak program can undermine otherwise well-designed encryption and network controls because an attacker with valid credentials appears authorized.<\/p>\n The most useful way to learn IAM is to separate concepts that are often blended together. Authentication is proof of identity; authorization is permission; federation lets one identity system assert information to another service; single sign-on reduces repeated authentication; and privileged-access controls protect especially powerful identities. Each layer can fail independently, so troubleshooting and security design should evaluate them separately.<\/p>\n Identity begins before the first login. Joiner, mover, and leaver processes should create accounts from authoritative records, assign access appropriate to a role, update privileges when responsibilities change, and disable or remove access promptly at departure. Orphaned accounts and stale group memberships accumulate when lifecycle events rely on manual memory. Automation can help, but only when ownership and source data are trustworthy.<\/p>\n Periodic access reviews catch mismatches that lifecycle workflows miss. Managers and application owners should confirm whether users still require access, especially to sensitive data and administrative functions. Reviews are most effective when entitlements are understandable. A list of cryptic group names encourages blind approval; mapping groups to business capabilities makes decisions more meaningful.<\/p>\n Lifecycle automation should include exception handling. Contractors, shared operations teams, mergers, leaves of absence, and emergency access rarely fit a single HR event. Define who can authorize these cases, how long access lasts, and how the identity is linked to an accountable owner. Temporary identities that have no expiration or sponsor often become long-lived orphan accounts.<\/p>\n Identity proofing is another lifecycle consideration. Creating an account based on an authoritative HR record differs from enrolling a consumer account with only email verification, and privileged identities may require stronger validation. The organization should know what evidence established each identity and when that evidence needs to be refreshed. Strong authentication cannot compensate for an identity that was issued to the wrong person or linked to an unverified sponsor.<\/p>\n Authentication asks whether the claimant can prove an identity. Passwords, hardware tokens, certificates, biometric factors, and device-bound credentials provide different forms of evidence. Authorization begins after identity is established and decides what resources or actions that identity may use. A perfectly authenticated user can still become a security problem if the application grants excessive permissions.<\/p>\n The distinction is visible in common failures. Credential theft is primarily an authentication problem; insecure direct object reference is primarily authorization. A session can be genuine yet overprivileged. The site\u2019s encryption and authentication distinction<\/a> is also important: an encrypted connection protects transport but does not by itself prove that a user should perform a sensitive action.<\/p>\n Authentication assurance should match action sensitivity. Reading a public dashboard and changing payroll data do not need identical proof requirements. Step-up authentication can require stronger verification for privileged or high-risk actions while keeping routine use efficient. Risk-based prompts should still be explainable and recoverable; a control that locks legitimate users out without a support path can create pressure for insecure bypasses.<\/p>\n Password policy should focus on resistance to guessing, reuse, and credential theft rather than arbitrary complexity alone. Long passphrases, compromised-password screening, rate limiting, and MFA can provide stronger practical protection than frequent forced changes that encourage predictable patterns. Authentication policy should consider the complete threat model, including recovery and credential stuffing, not just whether a password contains several character classes.<\/p>\n Multifactor authentication combines independent factor types such as knowledge, possession, and inherence. Two passwords are not two factors because both rely on knowledge. The value of MFA depends on the method and workflow. Phishing-resistant methods that bind authentication to the legitimate service provide stronger protection than approval prompts that can be socially engineered.<\/p>\n The MFA fundamentals<\/a> explain the factor model, but deployment details matter. Protect enrollment and recovery, require reauthentication for sensitive changes, and monitor new device registration. Repeated push prompts can create MFA fatigue<\/a>, so number matching, contextual prompts, rate limits, and stronger authenticators can reduce approval abuse.<\/p>\n MFA enrollment deserves the same scrutiny as login. An attacker who can add a new factor after compromising only a password may turn temporary access into durable control. Require appropriate proof for adding or replacing authenticators, notify users of changes, and monitor recovery events. Help-desk procedures are part of the authentication system because social engineering often targets the recovery path.<\/p>\n MFA design should also include resilience. Users can lose tokens, replace phones, travel without normal network access, or encounter inaccessible biometric sensors. Recovery methods must be secure enough that attackers cannot bypass MFA by calling support, yet usable enough that administrators do not create permanent exceptions. Test recovery paths with the same seriousness as primary login because attackers frequently choose the least protected enrollment or support workflow.<\/p>\n Single sign-on lets a user authenticate once and access multiple services without repeatedly entering credentials. Federation allows one identity provider to make assertions that another system trusts. Technologies such as SAML and OpenID Connect implement different federation patterns, while OAuth is primarily an authorization framework for delegated access. These systems reduce password sprawl but concentrate importance in the identity provider and trust configuration.<\/p>\nManage identity as a lifecycle<\/h3>\n
Keep authentication and authorization distinct<\/h3>\n
Use multifactor authentication for meaningful assurance<\/h3>\n
Understand SSO and federation trust<\/h3>\n