Onboarding a High-Churn Vendor Account Without Breaking Rotations
A regional hospital runs CyberArk PAM on-premises. The IT operations team has 14 administrators who access a shared local administrator account on 220 Windows servers via a Single Connection Account (SCA) through PSM. CPM rotates the local admin password every 24 hours. Last quarter, the vendor supporting the hospital's billing application (a third-party contractor) was granted access to a privileged domain service account svc_billing that CPM rotates every 7 days. The vendor's batch jobs authenticate with a static connection string stored in a config file on three application servers. Since onboarding, the vendor's nightly jobs fail roughly twice a week with authentication errors; the vendor's on-call engineer often calls the service desk at 02:00, and the service desk has begun manually resetting the password to a known value and emailing it to the vendor. Security wants to eliminate the email and the manual reset, but the vendor insists their application 'cannot do API calls' and 'cannot be changed.' The CPM administrator proposes simply disabling rotation for svc_billing to stop the failures.
1. Evaluate the CPM administrator's proposal to disable rotation. What is the most defensible alternative, and what reasoning supports it?
Read the worked answer
Disabling rotation converts a controlled, audited secret into a permanently static credential - the exact risk PAM exists to mitigate. It also leaves the manual-reset/email workaround in place, so nothing is actually fixed.
A better approach is to keep rotation and remove the consumer's dependence on the static value:
- Reduce blast radius first. Confirm what
svc_billingcan reach and trim its rights to the minimum the batch jobs need. A static secret in a config file is far worse if the account is domain-wide admin. - Introduce a reconciliation path the app can use. Even 'no API' apps usually read a file at startup or on a scheduled refresh. Options: a CPM-managed file that the app re-reads, a scheduled task that restarts the service after rotation, or a credential provider/proxy that injects the secret at connection time.
- If the app truly cannot change, the honest answer is a documented, time-bound exception with compensating controls (network restriction to the three app servers, alerting on use from anywhere else, shorter rotation with a coordinated restart window, and an owner-signed remediation date) - not silent indefinite rotation-off.
The judgment the exam is testing: 'the vendor says it can't change' is a constraint to manage, not a reason to abandon the control. Preserve rotation, shrink the exposure, and make any exception explicit and owned.
2. The service desk's manual reset-and-email practice is the immediate problem. How should it be handled, and what does it tell you about the deployment?
Read the worked answer
The manual reset-and-email is a shadow process that bypasses PAM entirely: the password leaves the vault, is transmitted insecurely, and is known to people outside the approved access path. It should be stopped as the first action - but stopping it without a replacement guarantees an outage and drives the workaround further underground.
Sequence it:
- Make the workaround visible and owned. Log it as an incident/risk, name an accountable owner, and set a date to retire it.
- Provide a legitimate path before removing the illegitimate one. E.g., the vendor's on-call engineer retrieves the credential through PSM/PSM for SSH or a vaulted checkout with approval and full session recording - with a defined after-hours approval flow so 02:00 doesn't force a workaround.
- Treat the workaround as a symptom. It appeared because the approved process failed at 02:00 with no fast path. Fix the fast path (after-hours approval, rotation windows aligned to the batch schedule) or the workaround returns.
What it tells you: the deployment optimized for 'vaulting credentials' but not for the operational reality of the credential's consumers. A PAM program that makes the secure path slower than the insecure one will always lose.