Identity And Access Management (IAM) Concepts
Identity and access management answers two questions on two timescales
A contractor's project ended in March, yet in June the contractor's account still opens the finance share; in the same company, a clerk who should only enter invoices can also approve them. Both are identity and access management (IAM) failures, one in each of the two parts of this domain. The identity life cycle works over time, asking whether an identity (the account a person, a service or an AI bot uses) should exist and hold its access right now; logical access controls check each request, deciding whether the subject (the person, process or device acting) may perform an operation such as read or edit on an object such as a file or a record, which is authorization. When the resource requires an authenticated identity, they use authentication to verify who the subject is. The classic trap is answering an authorization question with an authentication fix: a new password or an extra sign-in factor checks identity more strongly, but it does not by itself repair outdated or excessive permissions.
Two outline objectives: 3.1 identity life cycle management and 3.2 logical access controls
The CC exam outline covers four identity life cycle activities (the subtopic page presents them as four stages): roles definition (deciding what access a job needs), provisioning (granting approved access), review (checking that access is still needed) and deprovisioning (removing it when the need ends), supported by frameworks such as the account management control in NIST SP 800-53r5 and by identity governance tools. Logical access controls cover the rules a system applies to each request. On the authentication side they include multifactor authentication (sign-in evidence from at least two different categories: something you know, something you have and something you are). On the authorization side, the NIST Cybersecurity Framework (CSF) 2.0 says access permissions and authorizations incorporate the principles of least privilege (how much access a subject gets) and separation of duties (which responsibilities one person may combine). SP 800-53r5 control AC-3 (Access Enforcement) enforces approved authorizations (approved permissions), and its enhancements include the access control models (who decides access and on what basis). The OWASP Authorization Cheat Sheet adds default deny: an application should refuse any request no rule grants. The two parts meet at the role: roles definition decides what a role contains, and least privilege is the yardstick for how much it should contain.
For excessive or outdated permissions, change the access itself
Across both parts the defensible choice leaves access narrow and current: grant only what the task needs, keep incompatible duties with different people, issue individual rather than shared accounts for human users, remove access when the need ends rather than at the next scheduled review, and refuse any request no rule grants. Options that only strengthen the sign-in, such as a longer password, leave an excessive or outdated permission exactly where it was. The exception is a weakness in verifying who the subject is (authentication); there multifactor authentication can help. An authentication protocol that keeps sign-in secrets and codes from an attacker posing as the real service, without relying on the user's vigilance, is phishing-resistant. A second factor does not guarantee it: NIST SP 800-63B-4 says codes the user types in by hand are not phishing-resistant, because manual entry does not bind the code to the session being authenticated.