CPM Rotation Fallout and the Break-Glass Exception
A regional insurer runs 1,200 Windows servers, 250 Unix hosts, and 900 service accounts. It has onboarded 2,400 local administrator accounts and 380 domain administrator accounts into CyberArk PAM. CPM rotates all Windows passwords every 30 days. Four weeks after go-live, the service desk logs 35 lockouts per week: overnight batch jobs fail at 02:00, and three vendors report authentication failures. Investigation shows the affected accounts are non-interactive service accounts whose passwords are embedded in scheduled tasks and application configuration files. No application owner can say whether the app can call an API. Separately, the CIO wants to remove dual control from 12 break-glass accounts because an on-call engineer waited 20 minutes for a second approver during a Sev-1 outage. The security team also finds 40 Unix root accounts still using SSH keys that CPM does not manage, and those keys have not rotated in two years. The CISO asks for a decision within one week.
1. Which accounts should be taken out of CPM password rotation, and what should replace CPM for them? State the decision criteria, not just the answer.
Read the worked answer
Start by classifying accounts by consumption pattern, not by server tier. Interactive human accounts and shared administrative accounts belong in CPM because a person can retrieve the password through PVWA and the rotation is invisible to them. Non-interactive application accounts are different: a password change is a configuration change to the application, so CPM rotation creates outages unless the application can fetch the new value at runtime.
For those accounts, the first choice is CyberArk Secrets Manager (Conjur) or Application Access Manager with Central Credential Provider, so the application authenticates and retrieves the secret on each startup or connection. If the application truly cannot make an API call, the fallback is CPM with an approved change window and an application owner sign-off, or a reconciliation account that can reset the password if CPM loses management. Simply excluding the accounts from CPM is the worst option because they become unmanaged and invisible.
The decision criteria are: can the application fetch at runtime, can it tolerate a restart, does it support an SDK or REST call, and who owns the change? Accounts with no acceptable answer should be escalated as risk exceptions with compensating controls, not silently removed.
2. How should the team respond to the CIO's request to remove dual control from the 12 break-glass accounts?
Read the worked answer
Do not remove dual control across the board. The control exists to prevent a single compromised or malicious administrator from using emergency access without a witness. Removing it for all 12 accounts recreates exactly the risk the program was built to reduce.
A better design is to separate break-glass access from normal privileged access. Keep the accounts in a dedicated safe, grant access through a defined emergency workflow, and require a real-time alert to the SOC when the safe is opened. For a Sev-1 outage, a single authorized on-call engineer can be allowed to check out the credential, but the session is recorded and the password is rotated immediately after use. That is a risk-based exception: availability is preserved, and the detective controls compensate for the missing preventive control.
The team should also measure whether the 20-minute wait was caused by dual control or by approver availability. If approvers were simply not reachable, the fix is an on-call approver roster, not weakening the control. Present the CIO with the residual risk and the compensating controls in writing.
3. The 40 Unix root accounts use SSH keys that CPM does not manage. What is the correct remediation path, and why is leaving them unmanaged unacceptable?
Read the worked answer
Leaving the keys unmanaged is unacceptable because an unrotated SSH key is a permanent credential: anyone who copied it two years ago still has root access, and there is no password change to invalidate it. The audit finding is not cosmetic.
The remediation path depends on the platform and CPM support. CyberArk CPM can manage SSH keys on Unix through the appropriate Unix/SSH key platform, rotating the key pair and updating the authorized_keys file on the target. The team should onboard the root accounts as SSH key accounts rather than as password accounts, configure the correct logon and reconciliation accounts, and test rotation on a small group before scaling.
If a particular device or distribution cannot support automated key rotation, use PSM/PSMP to proxy the SSH access and store the key in the safe, so at least the key is vaulted and sessions are recorded. Then set a manual rotation schedule and track it as an exception. The key decision is to convert every root key into either a CPM-managed key or a vaulted key behind a proxy; neither option leaves it unmanaged.