CyberArk Guardian: Human Identity Security

The Human Identity Security domain tests workforce identity in CyberArk Identity: directory integration, single sign-on, multi-factor authentication, adaptive authentication, provisioning, and lifecycle management. Questions typically ask how a user authenticates, how an application is assigned, and how access is removed when a person changes roles or leaves.

Core rules

• Directories such as Active Directory, LDAP, or cloud directories are connected and synchronized. Directory membership alone does not grant application access; roles and policies do.
• SSO uses SAML or OIDC applications in the app catalog. Distinguish identity provider-initiated from service provider-initiated flows, and remember that SSO authenticates a user but does not by itself authorize every action inside an app.
• MFA factors include push, TOTP, FIDO2 security keys, SMS, email, and passwordless methods. Authentication profiles determine which factors are offered or required.
• Adaptive authentication evaluates conditions such as user, group, device, location, network, and risk. Rules are evaluated in order, and the outcome can allow, challenge with MFA, or deny.
• Provisioning uses SCIM or lifecycle workflows to create, update, and disable accounts. Attribute mapping must be correct, and deprovisioning must remove app accounts as well as directory access.
• Roles provide role-based access. A user receives app access through role membership, not merely by existing in the directory.

Worked example

A contractor in a high-risk country needs a payroll application. Reasoning: create or use a contractor role and assign the payroll app to that role; add the contractor to the role; create an adaptive policy that matches the high-risk location and requires a phishing-resistant factor such as FIDO2, or denies access if policy forbids it; use SCIM provisioning so the payroll account exists with correct attributes; schedule deprovisioning at contract end. SSO alone would not satisfy the location requirement.

Traps

• Confusing authentication with authorization; SSO does not grant app entitlements.
• Assuming directory synchronization automatically grants application access.
• Mis-mapping SCIM attributes, which creates duplicate or incomplete accounts.
• Treating push notification and FIDO2 as equivalent phishing-resistant factors.
• Placing a broad allow rule before a specific deny rule in adaptive policy.
• Disabling the directory account but leaving the SaaS app account active.