> ## Documentation Index
> Fetch the complete documentation index at: https://syteca.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.
# Rotate the Built-in Admin Password
> Use the Syteca ACB API to rotate the built-in admin user's password from your external secrets vault, CMDB, or compliance workflow — verify current password, then change to a new one.
## 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:
| Step | Endpoint | Purpose |
| ------------- | --------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------- |
| **1. Verify** | [`POST /api/auth/verify`](/docs/api/acb/endpoints/verify-password) | Confirm the stored value in your secrets vault matches the current admin password. Prevents desynchronization between the vault and Syteca. |
| **2. Change** | [`PUT /api/users/admin/password`](/docs/api/acb/endpoints/change-admin-password) | Rotate the admin password to a new value. |
A typical secrets vault rotation runner:
```text theme={"system"}
1. Read current admin password from vault
2. POST /api/auth/verify with current password
→ If verified=false: log alert, investigate desync, abort
3. Generate new password matching Syteca's policy
4. PUT /api/users/admin/password with new value
5. Write new password to vault
6. Verify the new value works (call /verify again, or test a non-admin endpoint)
```
## Prerequisites
These endpoints have a stricter user requirement than the rest of ACB:
| Requirement | Why |
| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------- |
| **An Internal or Active Directory user** *(not an Application Account)* with the [administrative User Management permission](/docs/administration/users/administrative-permissions) | Application Accounts can't hold the User Management permission, which is required to modify the admin user's password. |
| The user must have a Refresh Token configured via [Application Account Settings](/docs/api/acb/setup-user-account#configure-application-account-settings) | Same Refresh Token → Access Token model as the rest of ACB. |
| The Refresh Token holder must NOT be the built-in `admin` user itself | Avoids the chicken-and-egg problem during rotation. |
**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`](/docs/api/acb/endpoints/get-access-token), then `Authorization: ` header on the verify and change calls. See [API reference → Authentication](/docs/api/acb/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.
## Related
Step 1 — confirm the stored password is still current.
Step 2 — rotate to a new value.
Configure the Refresh Token user for admin-rotation duty.
All 9 user management endpoints in one place.