CyberArk Guardian cheat sheet

Core PAM objects: Safe (logical container), Account (credential or SSH key), Member (user, group, or service that can access a Safe), and Platform (connection and rotation policy for an account type).

Safe permissions are granted at Member level with levels: Use, Retrieve, List, Add, Update, Delete, Manage Safe, Manage Safe Members, Approve, Audit, View Audit, and Admin. 'Retrieve' allows password viewing; 'Use' allows CPM-driven connection without showing the password.

Dual control (two-person rule): a Safe can require one or two authorized approvers before a Retrieve or Connect action is fulfilled; the requester cannot approve their own request unless explicitly permitted.

CPM (Central Policy Manager) performs credential rotation per Platform settings; a Platform defines rotation period, verification period, change method, and reconciliation method. Verification checks validity without changing the secret.

PSM (Privileged Session Manager) proxies sessions to targets and records them; PSM records are stored in a vaulted location and indexed for playback. PSM Gateway provides isolated network access without a connector on the target network.

On-demand privilege elevation (EPV) rules grant time-limited access to a Safe or account based on a condition such as a ticketing system, a time window, or an approver; a rule can be enabled/disabled and has a validity period.

Ticketing integration: an ITSM rule validates a ticket ID and can auto-approve, deny, or require approval; the rule's scope is limited to specific Safes and can enforce a ticket-per-request or a single ticket for a session.

Session isolation and keystroke-level recording are PSM features; privileged session monitoring can be configured to alert or terminate a session when a suspicious pattern is detected, and PSM can enforce command allow/deny lists per Platform.

Account onboarding: an account is discovered via an automatic discovery scan, then reconciled into a Safe; the reconciliation account must have sufficient rights to change the target account's password and to verify it.

Human identity security controls who can authenticate as a person and what that person can do; the primary objects are users, groups, roles, and the authentication factors bound to them.

Authentication factors: something you know (password), something you have (OTP, FIDO2 key, push), something you are (biometrics). MFA requires at least two distinct factor types; two passwords are not MFA.

Adaptive/risk-based authentication evaluates signals such as device, location, time, and behavior; a high-risk score can force step-up authentication or block the session.

Least privilege for humans: role-based access with just-in-time elevation, periodic access reviews, and separation of duties to prevent a single person from both requesting and approving privileged access.

Privileged human accounts should be separate from day-to-day accounts; administrative accounts are vaulted, rotated, and only checked out for a defined duration.

Session monitoring for humans includes recording, live monitoring, and behavioral analytics; anomalies such as unusual hours or unusual command sequences trigger alerts.

Identity lifecycle: joiner-mover-leaver processes must revoke access on role change and termination; orphaned accounts are a common audit finding.

Passwordless and phishing-resistant authentication (FIDO2/WebAuthn) is preferred for high-privilege human accounts because it resists credential phishing and replay.

Audit evidence for human identity: authentication logs, access review attestations, and session recordings must be retained per policy and be attributable to a named individual.

Nonhuman identities include service accounts, application secrets, API keys, certificates, SSH keys, and tokens; they typically cannot perform MFA, so their security depends on vaulting, rotation, and scoping.

Secrets Manager centralizes secrets and provides retrieval via API/SDK; applications authenticate to the vault using a workload identity (for example, a platform-issued token or certificate) rather than a stored static secret.

Dynamic secrets are generated on demand with a short TTL and are revoked automatically; static secrets are stored and rotated on a schedule. Dynamic secrets reduce the blast radius of a leak.

Secret rotation must be coordinated with consumers: rotation changes the credential at the target and updates the vault; reconciliation handles drift when the target and vault disagree.

Secret sprawl is the presence of credentials in code, config files, CI/CD variables, or logs; detection requires scanning repositories and pipelines, and remediation moves the secret into the vault with a reference.

Certificate lifecycle management covers issuance, renewal, and revocation; short-lived certificates with automated renewal reduce the risk of expired or long-lived certificates.

Workload identity binding: a secret policy should restrict which workload (by namespace, service account, or IP) can read which secret path, enforcing least privilege for machines.

Machine identity governance requires an inventory of nonhuman identities, ownership assignment, and periodic review; unowned service accounts are a common attack path.

Secrets in CI/CD: pipelines should fetch secrets at runtime from the vault, never echo them, and mask them in logs; build artifacts must not embed credentials.

An agentic identity is a nonhuman identity that acts autonomously on behalf of a user or system; it needs its own credential, a defined scope, and an accountable owner, distinct from the human it represents.

Agent authorization should follow delegation: the agent receives a scoped, time-bound token derived from the delegating identity, and the token's permissions are the intersection of the agent's role and the delegator's rights.

Agent-to-agent and agent-to-resource calls should use short-lived tokens with audience restriction; a token issued for one service must be rejected by another.

Identity governance for agents includes registration, ownership, entitlement review, and decommissioning; an agent with no owner or no expiry is an orphaned privileged identity.

Identity governance core processes: access request and approval, provisioning/deprovisioning, access certification (recertification campaigns), and segregation-of-duties policy enforcement.

Access certification campaigns assign reviewers to attest entitlements; decisions are certify, revoke, or delegate, and the campaign produces audit evidence with reviewer and timestamp.

Segregation of duties detects toxic combinations of entitlements; a policy defines conflicting entitlement pairs, and a violation is either prevented at request time or flagged for remediation.

Role mining derives roles from existing entitlements; role explosion is the anti-pattern where too many fine-grained roles make governance unmanageable.

Governance metrics: percentage of entitlements certified on time, orphaned accounts, SoD violations open, and time-to-revoke on termination; these are the evidence auditors request.