Skip to main content

​
Stop treating the built-in admin password as the one credential you can’t rotate

Every privileged-access platform ships with a built-in admin account — and that account’s password is reliably the one credential customers forget to rotate. It gets used during installation, written into a runbook, copied into a knowledge-base article, and then sits unchanged for years while every other credential in the environment rotates on a regular schedule. Compliance frameworks notice: PCI DSS requires privileged-account password rotation, SOC 2 auditors flag stale admin passwords, HIPAA assessments treat built-in admin credentials as elevated risk. The competitive landscape on this specific topic is uneven. CyberArk rotates its own Vault admin via a separate RestAPI operation that requires a Privileged Threat Analytics integration to schedule. Delinea Secret Server’s built-in admin can be rotated through the standard secrets API, but only after manually creating a self-referencing secret. HashiCorp Vault doesn’t have a built-in admin in the same sense — its root token rotation is a deliberately heavyweight operation involving unsealing keys. Syteca exposes admin password rotation as two purpose-built REST endpoints in the ACB User Management API surface. Your external secrets vault verifies the current password, generates a new one, and updates it — same way it manages every other privileged credential. No separate connector product, no manual self-referencing secret setup, no unsealing key ceremony.
Use the ACB admin password rotation endpoints when you need to:
  • Meet PCI DSS / SOC 2 / HIPAA admin-account rotation requirements without manual operations.
  • Centralize built-in admin credentials in your enterprise secrets vault (CyberArk, HashiCorp Vault, AWS Secrets Manager) — and let the vault rotate them on schedule.
  • Rotate after credential exposure events — when an admin password may have been leaked, rotate immediately from your incident-response playbook.
  • Eliminate the runbook problem — admin passwords no longer live in runbooks, KB articles, or onboarding docs because they change frequently enough that documented values are obsolete within hours.
NOT AVAILABLE IN SAAS. ACB is on-premises only.

​
How it works

Two endpoints, used together in a verify-then-change pattern: A typical secrets vault rotation runner:

​
Prerequisites

These endpoints have a stricter user requirement than the rest of ACB:
Don’t use the built-in admin account itself as the Refresh Token holder. If you do, rotating the admin password during the API call mid-flight can invalidate the in-progress Access Token. Use a separate Internal or AD user with User Management permission instead.

​
Authentication

Same as the rest of ACB — Refresh Token → Access Token via POST /get_access_token, then Authorization: <AccessToken> header on the verify and change calls. See API reference → Authentication.

​
Rate limit

5 requests per minute per Access Token on both verify and change endpoints — admin password rotation is intentionally bandwidth-limited to make brute-force attacks impractical.

Verify admin password

Step 1 — confirm the stored password is still current.

Change admin password

Step 2 — rotate to a new value.

Set up user account

Configure the Refresh Token user for admin-rotation duty.

User Management endpoints

All 9 user management endpoints in one place.