Access Controls

2.1 Implement and maintain authentication methods

Core idea: authentication method selection.

Scenario: Remote administrators authenticate only with passwords to a portal that controls production systems.

Practitioner response: Require phishing-resistant or strong MFA, conditional access, and session monitoring for privileged remote access.

Concepts to Understand

• single-factor and multi-factor authentication: MFA matters most when password compromise would grant broad access. For privileged access, prefer phishing-resistant or strong MFA with monitored sessions.
• single sign-on: single sign-on is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• device authentication: device authentication is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• federated access: federated access is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• OAuth2, OIDC, and SAML: OAuth2, OIDC, and SAML is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.

2.2 Understand and support internetwork trust architectures

Core idea: trust boundaries.

Scenario: A partner API connection can reach internal services because it shares the same trust zone as employees.

Practitioner response: Constrain the third-party path through explicit trust boundaries, least privilege, monitoring, and scoped network/API controls.

Concepts to Understand

• one-way, two-way, transitive, and zero trust relationships: one-way, two-way, transitive, and zero trust relationships is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• internet, intranet, extranet, and DMZ: internet, intranet, extranet, and DMZ is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• third-party APIs, extensions, and middleware: third-party APIs, extensions, and middleware is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.

2.3 Support and implement identity management lifecycle

Core idea: identity lifecycle.

Scenario: A terminated employee loses email access but still has inherited access through nested groups in a file system.

Practitioner response: Review and remove inherited entitlements during de-provisioning and verify access removal through reporting.

Concepts to Understand

• authorization: authorization is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• identity proofing: identity proofing is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• provisioning and de-provisioning: provisioning and de-provisioning is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• monitoring, reporting, and maintenance: monitoring, reporting, and maintenance is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• entitlements and inherited rights: entitlements and inherited rights is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• IAM systems: IAM systems is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.

2.4 Understand and administer access controls

Core idea: authorization model selection.

Scenario: Access decisions must consider clearance, department, device posture, time, and data label.

Practitioner response: Use an access model that evaluates attributes and policy conditions, then monitor privileged exceptions.

Concepts to Understand

• mandatory access control: mandatory access control is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• discretionary access control: discretionary access control is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• role-based access control: role-based access control is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• rule-based access control: rule-based access control is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• attribute-based access control: attribute-based access control is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• privileged access management: privileged access management is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.

Authentication vs Authorization

Exam clue: If the user is logged in but can access another user record, the issue is authorization, not authentication.

RBAC vs ABAC vs DAC vs MAC

Exam clue: When many conditions drive a decision, ABAC is often stronger than trying to create endless roles.

SSO vs federation

This comparison is covered through the domain objectives above and the SSCP review sheet.

IAM vs PAM

This comparison is covered through the domain objectives above and the SSCP review sheet.