CyberArk SECRET-SEN common mistakes
CyberArk SECRET-SEN · Understand the traps and how to avoid them.
Treating every nonhuman identity as an 'account' in the Vault and designing onboarding around password rotation only, ignoring API keys, certificates, SSH keys, and tokens that are not stored as standard password accounts.
Candidates carry over traditional privileged access management (PAM) habits where 'account' equals username/password in a Safe. They underestimate the breadth of nonhuman identities (service accounts, API keys, certificates, SSH keys, tokens) and miss that CyberArk Secrets Manager supports multiple secret types and onboarding methods.
What to do instead
Memorize the categories of nonhuman identities and the corresponding secret types (password, SSH key, API key, certificate, token). Practice mapping each to the appropriate Secrets Manager capability: Accounts, SSH Key Manager, Certificate Manager, and external secret stores. Build a checklist that starts with identity discovery and classification before choosing an onboarding method.
Assuming the Vault is a single monolithic server and failing to plan for high availability, disaster recovery, and component placement (Vault, PVWA, CPM, PSM, Session Management) across network zones.
Candidates study features but not the reference architecture. They forget that the Vault must be deployed in a hardened, isolated network zone, that CPM and PSM require outbound connectivity to targets, and that replication and failover need dedicated ports and certificates.
What to do instead
Draw the CyberArk reference architecture from memory: Vault in the secure zone, PVWA/CPM/PSM in the management zone, targets in other zones. List required firewall rules and certificate requirements for each component. Review the official hardening and HA/DR guides, and practice sizing a small deployment with redundancy.
Designing Safe and policy structures that are too flat or too granular, leading to excessive standing access or unmanageable numbers of Safes and permissions.
Candidates focus on individual object permissions (Safe, user, group) without a model for role-based access control. They forget that Safe design should reflect least privilege, separation of duties, and the principle of unique ownership, and that dual control and exclusive access are policy settings, not just naming conventions.
What to do instead
Adopt a naming and hierarchy standard (e.g., by environment, application, and owner). Use groups for role-based access, apply dual control for sensitive Safes, and use exclusive access sparingly. Practice writing a Safe design document that maps business roles to Safe permissions and includes a review cadence.
Confusing the retrieval methods and their authentication flows: using the REST API with a user session instead of application authentication, or misconfiguring Central Credential Provider (CCP) application IDs and Safe permissions.
Candidates learn that 'applications can retrieve secrets' but do not distinguish between user-based retrieval (PVWA/REST with user credentials) and application-based retrieval (CCP, ASCP, Secrets Hub, SDKs). They overlook that the application identity must be mapped to an application ID and authorized on the Safe.
What to do instead
Create a comparison table of retrieval methods: PVWA UI, REST API with user authentication, CCP with application ID and hash, ASCP, and SDKs. For each, note authentication, authorization object, and typical use case. Practice configuring a CCP application and testing retrieval with a sample web app.
Embedding credentials in CI/CD pipeline variables or source code because 'the pipeline is secure', rather than integrating a secrets manager and short-lived credentials.
Candidates treat CI/CD as trusted and skip the step of externalizing secrets. They also misunderstand that pipeline logs, job artifacts, and third-party plugins can expose secrets, and that static credentials in variables violate the nonhuman identity lifecycle.
What to do instead
Learn the integration patterns: CyberArk Secrets Manager plugin for Jenkins, Azure DevOps, GitHub Actions, and GitLab; dynamic secrets via CCP/ASCP; and workload identity federation where available. Practice replacing a hardcoded secret with a retrieval step that authenticates the pipeline as an application identity and fetches the secret at runtime.
Ignoring the audit trail and remediation workflow: assuming that once a secret is vaulted it is secure, without monitoring for unmanaged secrets, stale accounts, or policy violations.
Candidates focus on onboarding and retrieval but skip governance. They do not know that CyberArk provides discovery, compliance reports, and remediation workflows (e.g., Secrets Hub, discovery scans, and account reconciliation) to find and fix unmanaged secrets.
What to do instead
Study the governance features: discovery and onboarding of unmanaged accounts, account reconciliation, compliance reports, and audit logs. Practice designing a remediation workflow: discover, classify, onboard, rotate, and monitor. Know which reports show stale or non-compliant accounts and how to schedule them.
Misunderstanding the role of the Central Policy Manager (CPM) and assuming it only rotates passwords, missing its responsibilities for reconciliation, verification, and management of SSH keys and other secret types.
Candidates reduce the CPM to a password rotator. They forget that the CPM also verifies credentials, reconciles accounts after failures, and can manage SSH keys and other platforms via plugins. This leads to poor troubleshooting when rotation fails.
What to do instead
List CPM responsibilities: rotate, verify, reconcile, and manage. Learn the CPM workflow and logs, and how platform settings (e.g., rotation period, retry, reconciliation) affect behavior. Practice troubleshooting a failed rotation by checking the CPM log and platform configuration.
Assuming that network segmentation alone protects the Vault, and neglecting Vault hardening, firewall rules, and the principle of least connectivity between components.
Candidates rely on the Vault being 'behind a firewall' and skip the detailed hardening steps: disabling unnecessary services, restricting inbound ports, using dedicated service accounts, and enabling audit. They also forget that the Vault must be patched and monitored.
What to do instead
Review the CyberArk Vault hardening guide and produce a checklist: OS hardening, Vault service account, firewall rules (only required ports from PVWA/CPM/PSM), audit policy, and backup encryption. Practice validating connectivity with a port matrix and documenting exceptions.
Confusing authentication methods for applications (e.g., using a user's credentials for an application) and failing to implement secure application authentication such as certificate-based or hash-based authentication for CCP.
Candidates learn that CCP uses an application ID but do not understand the authentication options (OS user, certificate, hash) and their security implications. They default to weak or misconfigured authentication, exposing secrets to unauthorized processes.
What to do instead
Study the CCP authentication methods and when to use each: OS user authentication, certificate authentication, and hash authentication. Practice configuring each in a lab, and know how to restrict application IDs to specific Safes and accounts. Test that unauthorized applications are denied.
Treating the exam as a product feature list and not practicing scenario-based design, so they cannot choose the right tool (e.g., CCP vs. Secrets Hub vs. PSM) for a given use case.
Candidates memorize features but do not map them to business problems. The exam tests judgment: which retrieval method for a containerized app, how to onboard a cloud IAM key, or when to use session isolation. Without scenario practice, they pick a familiar tool regardless of fit.
What to do instead
Build a decision matrix: for each scenario (web app, CI/CD pipeline, cloud workload, database, SSH), list the recommended CyberArk component and the reasons. Practice with sample scenarios and justify choices in terms of security, operational overhead, and compliance. Review official solution guides for common patterns.