What it does. Deploy CyberArk Secure Cloud Access (SCA) to eliminate standing privileges in AWS, Azure, and GCP by provisioning ephemeral, scoped roles on a just-in-time basis governed by the TEA framework (Time, Entitlements, Approvals). Use when designing or implementing zero standing privilege / just-in-time privileged access models with CyberArk, or when replacing persistent cloud admin roles with time-bound, approval-gated sessions. Part of mukul975/Anthropic-Cybersecurity-Skills (817 security skills) (mukul975/Anthropic-Cybersecurity-Skills).

Upstream	mukul975/Anthropic-Cybersecurity-Skills
Skill file	skills/implementing-zero-standing-privilege-with-cyberark/SKILL.md
License	Apache-2.0 (skill folder LICENSE)
Author	mukul975
Fetched	2026-09-10

Install

• npx skills add mukul975/Anthropic-Cybersecurity-Skills --skill implementing-zero-standing-privilege-with-cyberark, or copy the skill folder into ~/.claude/skills/implementing-zero-standing-privilege-with-cyberark/.
• Raw file: curl -sL https://raw.githubusercontent.com/mukul975/Anthropic-Cybersecurity-Skills/HEAD/skills/implementing-zero-standing-privilege-with-cyberark/SKILL.md

SKILL.md (verbatim)

name: implementing-zero-standing-privilege-with-cyberark
description: Deploy CyberArk Secure Cloud Access (SCA) to eliminate standing privileges in AWS, Azure, and GCP by provisioning ephemeral, scoped roles on a just-in-time basis governed by the TEA framework (Time, Entitlements, Approvals). Use when designing or implementing zero standing privilege / just-in-time privileged access models with CyberArk, or when replacing persistent cloud admin roles with time-bound, approval-gated sessions.
domain: cybersecurity
subdomain: identity-access-management
tags:
- cyberark
- zero-standing-privilege
- jit-access
- pam
- cloud-security
- least-privilege
version: '1.0'
author: mahipal
license: Apache-2.0
nist_csf:
- PR.AA-01
- PR.AA-02
- PR.AA-05
- PR.AA-06
mitre_attack:
- T1078
- T1110
- T1556
- T1098
- T1078.004

Implementing Zero Standing Privilege with CyberArk

Overview

Zero Standing Privileges (ZSP) is a security model where no user or identity retains persistent privileged access. Instead, elevated access is provisioned dynamically on a just-in-time (JIT) basis and automatically revoked after use. CyberArk implements ZSP through its Secure Cloud Access (SCA) module, which creates ephemeral, scoped roles in cloud environments (AWS, Azure, GCP) that exist only for the duration of a session. The TEA framework -- Time, Entitlements, and Approvals -- governs every privileged access session.

When to Use

• When deploying or configuring implementing zero standing privilege with cyberark capabilities in your environment
• When establishing security controls aligned to compliance requirements
• When building or improving security architecture for this domain
• When conducting security assessments that require this implementation

Prerequisites

• CyberArk Identity Security Platform (Privilege Cloud or self-hosted)
• CyberArk Secure Cloud Access (SCA) license
• Cloud provider accounts (AWS, Azure, GCP) with admin access for integration
• ITSM integration (ServiceNow, Jira) for approval workflows
• CyberArk Vault configured with safe management

Core Concepts

TEA Framework (Time, Entitlements, Approvals)

Component	Description	Configuration
Time	Duration of the privileged session	Min 15 minutes, max 8 hours, default 1 hour
Entitlements	Permissions granted during the session	Dynamically scoped IAM roles/policies
Approvals	Authorization workflow before access	Auto-approve, manager approval, or multi-level

ZSP Architecture

User requests access via CyberArk
        │
        ├── CyberArk evaluates request against policies:
        │   ├── Is user eligible for this access?
        │   ├── Does the request comply with TEA policies?
        │   └── Is approval required?
        │
        ├── [If approval needed] → Route to approver (ITSM/ChatOps)
        │
        ├── Upon approval:
        │   ├── CyberArk creates ephemeral IAM role in target cloud
        │   ├── Scopes permissions to minimum required entitlements
        │   ├── Sets session TTL (time-bound)
        │   └── Provisions temporary credentials
        │
        ├── User accesses cloud resources via session
        │   ├── All actions logged and recorded
        │   └── Session monitored for policy violations
        │
        └── Session expires:
            ├── Ephemeral role deleted
            ├── Temporary credentials revoked
            └── Zero standing privileges remain

CyberArk Components

Component	Role
Identity Security Platform	Central management and policy engine
Privilege Cloud Vault	Stores privileged credentials and keys
Secure Cloud Access	Creates/destroys ephemeral cloud roles
Endpoint Privilege Manager	Controls local admin and app elevation
Privileged Session Manager	Records and monitors privileged sessions

Workflow

Step 1: Integrate Cloud Providers

AWS Integration:

1. Create a CyberArk integration role in AWS IAM
2. Configure cross-account trust policy allowing CyberArk to assume roles
3. Create IAM policies that define maximum allowed entitlements
4. Register AWS accounts in CyberArk SCA

{
    "Version": "2012-10-17",
    "Statement": [{
        "Effect": "Allow",
        "Principal": {
            "AWS": "arn:aws:iam::CYBERARK_ACCOUNT:role/CyberArkSCARole"
        },
        "Action": "sts:AssumeRole",
        "Condition": {
            "StringEquals": {
                "sts:ExternalId": "cyberark-external-id"
            }
        }
    }]
}

Azure Integration:

1. Register CyberArk as an enterprise application in Microsoft Entra ID
2. Grant CyberArk application permissions: Directory.ReadWrite.All, RoleManagement.ReadWrite.Directory
3. Create custom Azure roles with scoped permissions
4. Register Azure subscriptions in CyberArk SCA

GCP Integration:

1. Create a service account for CyberArk in GCP
2. Grant IAM Admin and Service Account Admin roles
3. Configure workload identity federation for cross-cloud access
4. Register GCP projects in CyberArk SCA

Step 2: Define Access Policies

Create policies that map job functions to cloud entitlements:

# CyberArk SCA Policy Example
policy_name: "developer-aws-read-access"
description: "Read-only access to AWS production for developers"
target_cloud: "aws"
target_accounts: ["123456789012", "987654321098"]

time_policy:
  max_duration: "4h"
  default_duration: "1h"
  business_hours_only: true
  timezone: "America/New_York"

entitlement_policy:
  aws_managed_policies:
    - "arn:aws:iam::aws:policy/ReadOnlyAccess"
  deny_actions:
    - "iam:*"
    - "organizations:*"
    - "sts:*"
  resource_restrictions:
    - "arn:aws:s3:::production-*"

approval_policy:
  approval_required: true
  approvers:
    - type: "manager"
    - type: "group"
      group: "cloud-security-team"
  auto_approve_conditions:
    - previous_approved_same_policy: true
      within_days: 7
  escalation_timeout: "2h"
  escalation_approver: "cloud-security-lead"

Step 3: Configure Session Monitoring

Set up privileged session recording and real-time monitoring:

1. Enable session recording for all ZSP sessions
2. Configure keystroke logging for SSH/RDP sessions
3. Set up real-time alerts for suspicious activities:
   • Attempts to escalate privileges during session
   • Access to resources outside policy scope
   • Session duration exceeding 2x the normal pattern
4. Forward session metadata to SIEM

Step 4: Implement Approval Workflows

Integrate with ITSM tools for access request and approval:

• ServiceNow: CyberArk SCA connector creates ServiceNow tickets for approval
• Slack/Teams: ChatOps bot for quick approvals within messaging platforms
• Jira: Integration for development-related access requests
• Auto-Approval: Configure rules for low-risk, previously approved requests

Step 5: Migrate from Standing Privileges

Phase 1: DISCOVERY (Weeks 1-2)
    ├── Inventory all standing privileged roles across cloud accounts
    ├── Map users to their standing role assignments
    ├── Analyze CloudTrail/activity logs for actual permission usage
    └── Identify roles that can be converted to JIT

Phase 2: POLICY CREATION (Weeks 3-4)
    ├── Create ZSP policies based on actual usage analysis
    ├── Define TEA parameters for each policy
    ├── Configure approval workflows
    └── Test policies with pilot users

Phase 3: MIGRATION (Weeks 5-8)
    ├── Assign ZSP policies to pilot group
    ├── Remove standing privileges from pilot users
    ├── Monitor for access issues and adjust policies
    ├── Expand to additional teams incrementally
    └── Remove all standing privileges organization-wide

Phase 4: GOVERNANCE (Ongoing)
    ├── Monthly review of ZSP policy effectiveness
    ├── Quarterly entitlement optimization
    ├── Monitor for policy drift or standing privilege re-creation
    └── Report ZSP metrics to security leadership

Validation Checklist

• Cloud providers integrated with CyberArk SCA
• TEA policies defined for all privileged access scenarios
• Approval workflows configured and tested
• Session recording and monitoring enabled
• All standing privileged roles identified for migration
• Pilot group successfully using ZSP without standing privileges
• Break-glass procedure defined for emergency access
• SIEM integration receiving session and access logs
• Auto-approval rules configured for low-risk, repeat access
• Organization-wide migration plan approved and scheduled
• KPI tracking: reduction in standing privilege assignments

References

• CyberArk Zero Standing Privileges
• CyberArk ZSP Implementation with AWS
• CyberArk Blueprint - Zero Standing Privilege
• CyberArk Secure Cloud Access Documentation

Other files in this skill

• LICENSE
• assets/template.md
• references/api-reference.md
• references/standards.md
• references/workflows.md
• scripts/agent.py
• scripts/process.py

assets/template.md (verbatim)

Zero Standing Privilege Implementation Template

Project Overview

Field	Value
Organization
CyberArk Platform Version
Target Clouds	AWS / Azure / GCP
Project Lead
Start Date

Standing Privilege Inventory

Identity	Cloud	Type	Admin Policy	Last Used	Migration Wave
	AWS/Azure/GCP	User/Role

ZSP Policy Definitions

Policy Name	Target Cloud	Entitlements	Max Duration	Approval	Certifier
				Auto/Manual

Migration Progress

Wave	Team	Identities	Migrated	Standing Removed	Status
1			Yes/No	Yes/No

Validation

• All standing privileges discovered and documented
• ZSP policies created for each access pattern
• Approval workflows tested end-to-end
• Pilot migration successful
• All standing privileges removed after migration
• Break-glass procedure documented and tested
• Session monitoring and recording enabled
• SIEM integration receiving ZSP access logs

references/api-reference.md (verbatim)

API Reference: CyberArk Zero Standing Privilege

CyberArk PVWA REST API v2

Authentication

POST /api/auth/CyberArk/Logon
Body: {"username": "admin", "password": "pass"}
Returns: Session token string

Key Endpoints

Method	Endpoint	Description
GET	/api/Safes	List all safes
GET	/api/Safes/{name}/Members	List safe members and permissions
GET	/api/Platforms	List configured platforms
GET	/api/Accounts	List privileged accounts
GET	/api/LiveSessions	List active privileged sessions
POST	/api/Accounts/{id}/CheckIn	Release exclusive account access

Safe Member Permissions

Permission	ZSP Implication
useAccounts	Can initiate privileged sessions
retrieveAccounts	Can retrieve passwords
listAccounts	Can see account inventory
requestsAuthorizationLevel1	Dual-control approval required

Session Properties

Field	Description
User	Session initiator
AccountName	Target privileged account
Duration	Session length in seconds
RemoteMachine	Target host

TEA Framework

Component	API Field	Purpose
Time	MaxSessionDuration	Auto-revoke after timeout
Entitlements	AllowedPermissions	Scoped access per session
Approvals	requestsAuthorizationLevel	Require approval workflow

References

• CyberArk REST API: https://docs.cyberark.com/pam-self-hosted/latest/en/Content/SDK/CyberArk%20REST%20API.htm
• CyberArk Secure Cloud Access: https://docs.cyberark.com/secure-cloud-access/

references/standards.md (verbatim)

Zero Standing Privilege with CyberArk - Standards Reference

Zero Trust Frameworks

NIST SP 800-207 - Zero Trust Architecture

• Never trust, always verify
• Least privilege access to resources
• Microsegmentation and policy enforcement points
• Dynamic, risk-based access policies

CISA Zero Trust Maturity Model

• Identity pillar: JIT/JEA access for all identities
• Advanced maturity: Automated privilege provisioning/deprovisioning
• Optimal maturity: Continuous verification with ephemeral access

TEA Framework Components

Time

• Session duration: minimum required for task completion
• CyberArk default: 1 hour, configurable 15 min to 8 hours
• Business hours enforcement optional
• Auto-termination on session inactivity

Entitlements

• Principle of least privilege
• Dynamic role creation scoped to specific resources
• Permission boundaries to prevent escalation
• Entitlement analytics for right-sizing

Approvals

• Risk-based approval routing
• Multi-level approval for critical access
• Auto-approval for previously approved, low-risk requests
• ITSM integration (ServiceNow, Jira) for audit trail

Compliance Requirements

SOC 2 - CC6

• CC6.1: Logical access security restricted
• CC6.3: Access authorized, modified, removed timely
• ZSP provides evidence of no standing privileges

PCI DSS v4.0

• 7.2.1: Access limited to least privilege
• 7.2.4: Access reviewed at least every 6 months
• ZSP eliminates the review burden by removing standing access

SOX Section 404

• Separation of duties enforcement
• Access to financial systems must be controlled
• JIT access provides clear audit trail of who accessed what, when

references/workflows.md (verbatim)

Zero Standing Privilege with CyberArk - Workflows

JIT Access Request Workflow

Developer needs to access AWS production environment
    │
    ├── Opens CyberArk Secure Cloud Access portal
    │
    ├── Selects target: AWS Account "Production" (123456789012)
    │
    ├── Selects policy: "Developer Production Read Access"
    │
    ├── Specifies duration: 2 hours
    │
    ├── Provides justification: "Investigating PROD-1234 latency issue"
    │
    ├── Submits request
    │
    ├── CyberArk evaluates TEA policy:
    │   ├── Time: 2 hours within allowed range
    │   ├── Entitlements: Read-only production access
    │   └── Approval: Manager approval required
    │
    ├── Approval request sent to manager (Slack/email)
    │
    ├── Manager approves
    │
    ├── CyberArk provisions ephemeral IAM role:
    │   ├── Creates role with ReadOnlyAccess + resource restrictions
    │   ├── Sets session duration to 2 hours
    │   └── Generates temporary STS credentials
    │
    ├── Developer accesses AWS console/CLI with temp credentials
    │   └── All actions recorded in session log
    │
    └── After 2 hours: role deleted, credentials revoked

Standing Privilege Migration Workflow

Phase 1: DISCOVERY AND ANALYSIS
    ├── Export all IAM users/roles with standing admin access
    ├── Analyze CloudTrail logs for actual permission usage
    ├── Identify which permissions are actually used vs. assigned
    ├── Calculate right-sized policy for each use case
    └── Map standing privileges to CyberArk ZSP policies

Phase 2: POLICY CREATION
    ├── Create CyberArk SCA policies for each access pattern
    ├── Define TEA parameters:
    │   ├── Maximum session duration per policy
    │   ├── Entitlement scope (AWS managed policies + custom)
    │   └── Approval requirements (auto vs. manual)
    ├── Configure approval workflows
    └── Test policies with pilot group

Phase 3: PILOT MIGRATION (2-4 weeks)
    ├── Assign ZSP policies to pilot users
    ├── Remove standing privileges from pilot users
    ├── Monitor for access denied errors
    ├── Adjust policies based on feedback
    └── Measure: request volume, approval time, session duration

Phase 4: FULL MIGRATION (4-8 weeks)
    ├── Migrate teams in waves (1 team per week)
    ├── Remove standing privileges after ZSP confirmed working
    ├── Configure auto-detect for new standing privilege creation
    └── Report metrics to security leadership

Phase 5: CONTINUOUS GOVERNANCE
    ├── Weekly: Review and right-size ZSP policies
    ├── Monthly: Audit for any standing privilege re-creation
    ├── Quarterly: Entitlement optimization report
    └── Alert on: New standing admin roles created outside CyberArk

Emergency Break-Glass Workflow

CyberArk SCA unavailable or network issue
    │
    ├── Retrieve break-glass credentials from:
    │   ├── Physical safe (sealed envelope)
    │   ├── Or secondary vault (Azure Key Vault / AWS Secrets Manager)
    │
    ├── Authenticate with break-glass credentials
    │
    ├── Perform emergency actions
    │
    ├── Document all actions taken
    │
    └── Post-incident:
        ├── Rotate break-glass credentials
        ├── Review session logs for the emergency access
        ├── File incident report
        └── Verify no unauthorized changes made

Back to mukul975/Anthropic-Cybersecurity-Skills (817 security skills) or Agent skills.