CPM Rotation Failures on Cisco and Fortinet Devices
A utility company manages 120 Cisco IOS switches and 60 Fortinet firewalls. The network team authenticates with TACACS+ personal accounts, and a shared local enable secret is stored as an extra password on each Cisco account. CPM uses a cloned Cisco platform with a 60-day rotation. Nine devices fail CPM password changes with authentication failed after three attempts, and 15 devices fail with prompt not found after an SSH banner change. Another 10 devices have passwords changed manually by a vendor last week. The CPM service account is locked out on two switches. The network team wants to disable CPM on all network devices and rotate manually. The security team wants no shared enable secret and full automation.
1. Diagnose the two failure classes and propose platform/CPM changes that avoid lockouts.
Read the worked answer
Separate the two failures. Authentication failed after three attempts usually means CPM is using an expired, wrong, or unauthorized logon account, not that the device is broken. Check the account Logon Account, TACACS+ authorization, and whether the CPM retry count exceeds the switch lockout threshold. Set CPM retries to one, lengthen the schedule, unlock the account, and test with Logon before another change. Prompt not found after a banner change is a connection-component parsing problem: inspect the SSH login and enable prompts, update the expected prompt or regular expression, and test the change component in isolation. Do not mass-change all devices to fix one prompt. Use a canary device per model, capture CPM logs, then roll out. The manual changes are a third class: verify first, then reconcile with a known working logon account.
2. How would you handle the shared enable secret and the 10 manually changed accounts in the short term?
Read the worked answer
Short term, stop the bleeding: disable automatic rotation on the two locked switches, unlock the CPM account, and set those devices to manual or reconcile-only until a canary succeeds. For the shared enable secret, move it to an Extra Password managed by CPM and rotate it with the device password, or model it as a dependent secret with its own rotation; do not leave it as an unmanaged note. For the 10 vendor-changed accounts, obtain the current password through a controlled handoff, use Verify and Logon, then Reconcile in a window. Do not use Change immediately because CPM would overwrite a password the vendor may still need. Record an exception with an expiry and owner so the manual state does not become permanent.
3. What is your recommendation on disabling CPM versus full automation? Provide a risk-based decision.
Read the worked answer
Do not disable CPM across the network estate; that trades an automation problem for a shared-secret and stale-password problem. Use a risk-tiered model: core switches and firewalls get CPM with one retry, a maintenance window, canary testing, and a documented logon account; vendor-managed devices get reconcile-only or manual with PSM recording and time-bound exceptions. TACACS+ per-user authentication plus PSM for network sessions gives accountability; the enable secret should be rotated by CPM and never shared in tickets. If the team cannot meet the rotation window, reduce scope rather than switch off management. The decision should be based on lockout risk, vendor access, and audit evidence, not on one prompt failure.