Credential Rotation

Secrets Manager can automatically rotate credentials so that long-lived passwords never become a liability. Rotation replaces the active credential on both the target system and inside SyVault in a single atomic operation.

Rotation Strategies

Time-Based Rotation

A rotation schedule triggers credential replacement at a fixed interval. Configure this from the secret's detail page in the web vault:

• Every 24 hours — high-security environments.
• Every 7 days — standard production workloads.
• Every 30 days — low-risk internal services.

When the interval elapses, Secrets Manager executes the rotation workflow automatically. Clients fetching the secret after rotation receive the new credential without any configuration change.

Event-Driven Rotation

Rotation can also be triggered by external events:

• Breach detection — an SIEM or monitoring system calls the SyVault API to force immediate rotation.
• Employee offboarding — an HR automation rotates all credentials the departing employee had access to.
• Manual trigger — an operator runs sy secret rotate <UID> from the CLI.

# Force immediate rotation of a specific secret
sy secret rotate 7Kj9mNpQ2xRs

Rotation Workflow

Every rotation follows a four-step sequence that ensures zero downtime:

1. Generate   →  Create new credentials (random password or database role)
2. Update     →  Apply the new credentials to the target system
3. Store      →  Write the new credentials into the SyVault secret record
4. Revoke     →  Remove the old credentials from the target system

If any step fails, the rotation is rolled back and an alert is sent to the application's configured notification channel. The old credential remains active so that running services are not disrupted.

Supported Targets

PostgreSQL

Secrets Manager connects to your PostgreSQL instance using a privileged management account and executes:

-- Step 1–2: Create new role
CREATE ROLE app_prod_a8f3 WITH LOGIN PASSWORD 'generated-password'
  IN ROLE app_prod_group;

-- Step 3: (SyVault updates the secret record internally)

-- Step 4: Revoke old role
REVOKE ALL PRIVILEGES ON ALL TABLES IN SCHEMA public FROM app_prod_7b21;
DROP ROLE app_prod_7b21;

The management account needs CREATEROLE privilege. SyVault generates a unique role name for each rotation cycle so the old and new roles can coexist during the transition window.

MySQL

The MySQL rotation target follows the same pattern:

-- Step 1–2: Create new user
CREATE USER 'app_prod_a8f3'@'%' IDENTIFIED BY 'generated-password';
GRANT SELECT, INSERT, UPDATE, DELETE ON mydb.* TO 'app_prod_a8f3'@'%';

-- Step 4: Revoke old user
DROP USER 'app_prod_7b21'@'%';

The management account needs CREATE USER and GRANT OPTION privileges.

Configuring a Rotation Target

1. Open the secret in the web vault.
2. Click Rotation Settings.
3. Select the target type (PostgreSQL or MySQL).
4. Provide the management connection string:

   postgresql://vf_admin:mgmt-password@db.example.com:5432/mydb

5. Set the rotation interval or leave it as manual-only.
6. Click Save.

SyVault validates the management connection before saving. If the connection fails, the configuration is rejected.

Monitoring Rotations

The Rotation History tab on each secret shows:

Timestamp	Status	Old Role	New Role	Duration
2026-04-05 03:00	Success	app_prod_7b21	app_prod_a8f3	1.2s
2026-03-06 03:00	Success	app_prod_3ef9	app_prod_7b21	0.9s

Failed rotations include the error message and a Retry button.

Grace Period

After a rotation completes, SyVault keeps the old credential valid for a configurable grace period (default: 60 seconds). This allows in-flight requests that cached the old credential to finish without errors. After the grace period, the old credential is revoked.

Best Practices

• Start with a 30-day interval and shorten it once you have confidence in your rotation pipeline.
• Test rotations in staging before enabling them in production.
• Monitor for rotation failures using webhooks (vault.record.rotated, vault.record.rotation_failed) and route them to your alerting system.
• Use dynamic secrets for databases when possible. Dynamic secrets are created on demand and automatically expire, eliminating the need for rotation entirely.