> ## Documentation Index
> Fetch the complete documentation index at: https://infisical.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Secret rotation

> Learn how to set up automated secret rotation in Infisical.

## Introduction

Secret rotation is a security best practice that involves systematically updating credentials and access tokens at regular intervals to minimize the risk of compromise. By proactively replacing existing secrets with new ones, organizations reduce the potential impact of credential theft or leakage.

Examples of rotated secrets include:

* API keys and authentication tokens for cloud services and third-party integrations
* Database credentials across production, staging, and development environments

## Supported providers

Search secret rotations

Filter secret rotations

found

## How rotation works

Infisical supports two rotation models: **Dual-Phase** (used by most providers) and **Single-Phase**. Select a tab below to learn how each model works.

> [tab] Dual-Phase
>
> Dual-phase rotation is the recommended approach that ensures zero downtime for your applications. This model systematically replaces secrets at regular intervals using an overlapping lifecycle that maintains continuous availability while enhancing your security posture.
>
> ### Visual timeline
>
> ```mermaid theme={"dark"}
> gantt
>     title Credential Lifecycle (Interval = 30 days)
>     dateFormat  YYYY-MM-DD
>     axisFormat %b %d
>
>     section Credentials 1
>     Active      :active, a1, 2023-01-01, 30d
>     Inactive    :done, i1, after a1, 30d
>     Revoked     :crit, r1, after i1, 30d
>
>     section Credentials 2
>     Active      :active, a2, 2023-01-31, 30d
>     Inactive    :done, i2, after a2, 30d
>     Revoked     :crit, r2, after i2, 30d
>
>     section Credentials 3
>     Active      :active, a3, 2023-03-02, 30d
>     Inactive    :done, i3, after a3, 30d
>     Revoked     :crit, r3, after i3, 30d
> ```
>
> ### Credential states
>
> Each set of credentials transitions through three distinct states:
>
> * **Active**: The primary credentials
> * **Inactive**: These credentials are still valid, but will be revoked in the next rotation
> * **Revoked**: Permanently invalidated and deleted from the system
>
> ### Rotation cycle example (30-day interval)
>
> Using a **30-Day** rotation interval as an example, here's how the process unfolds:
>
> 1. **Day 0**
>    * `Credential set 1` is issued and set to **Active**
>    * Applications begin using this set for authentication
>
> 2. **Day 30**
>
>    * `Credential set 2` is issued and set to **Active**
>
>    * `Credential set 1` transitions to **Inactive** but remains valid
>
>    * New applications will utilize set 1, while existing applications with set 1 continue to work
>
>    > [!NOTE]
>    >
>    > This overlapping validity period ensures that at any point during the active period of a credential set, you are guaranteed that retrieved credentials will be valid for the specified rotation period.
>
> 3. **Day 60**
>    * `Credential set 3` is issued and set to **Active**
>    * `Credential set 2` transitions to **Inactive** but remains valid
>    * `Credential set 1` is **Revoked** and securely deleted
>    * By now, all applications should have transitioned to using set 2 or 3
>
> 4. **Day 90**
>    * `Credential set 4` is issued and set to **Active**
>    * `Credential set 3` transitions to **Inactive** but remains valid
>    * `Credential set 2` is **Revoked** and securely deleted
>    * The cycle continues...
>
> ### Benefits
>
> * **Zero Downtime**: Applications always have valid credentials
> * **Grace Period**: The inactive period gives applications time to update to new credentials
> * **Reduced Risk**: Credentials are regularly cycled, limiting the impact of potential compromise
> * **Predictable Schedule**: Makes credential management more systematic and easier to automate
>
> ### Implementation considerations
>
> * Choose a rotation interval appropriate for your security requirements and operational needs
> * Ensure your applications can handle credential updates gracefully
> * Monitor for applications still using credentials nearing revocation

> [tab] Single-Phase
>
> Some providers have technical limitations that prevent dual-phase rotation. These providers use **single-phase rotation**, which updates a single credential in place. When rotation occurs, old credentials become invalid immediately—there is no overlap period.
>
> This means that clients using the previous credentials will fail to authenticate until they retrieve the new credentials.
>
> > [!WARNING]
> >
> > Single-phase rotation may cause brief service interruptions. For these providers, we recommend disabling auto-rotation and performing manual rotations during scheduled maintenance windows.
>
> ### Why single-phase?
>
> Some credential providers have limitations that require single-phase rotation:
>
> * The third-party provider's API only supports managing one active credential set at a time
> * The specific use-case (such as personal login accounts) is inherently limited to a single active credential
>
> ### Recommendations
>
> When using single-phase rotation with service continuity requirements:
>
> * **Disable auto-rotation** and perform manual rotations during scheduled maintenance windows
> * **Coordinate with dependent services** to ensure they can quickly retrieve new credentials
> * **Monitor authentication failures** after rotation to detect any services that failed to update

## Database credential rotations

For most providers, including Redis and API key providers such as AWS and Cloudflare, Infisical issues a new credential on each rotation and removes the old one once it has been replaced.

Database rotations work differently. Infisical never creates or drops users in [PostgreSQL](https://infisical.com/docs/documentation/platform/secret-rotation/postgres-credentials.md), [MySQL](https://infisical.com/docs/documentation/platform/secret-rotation/mysql-credentials.md), [Microsoft SQL Server](https://infisical.com/docs/documentation/platform/secret-rotation/mssql-credentials.md), [Oracle Database](https://infisical.com/docs/documentation/platform/secret-rotation/oracledb-credentials.md), [MongoDB](https://infisical.com/docs/documentation/platform/secret-rotation/mongodb-credentials.md), or [ClickHouse](https://infisical.com/docs/documentation/platform/secret-rotation/clickhouse-credentials.md). Doing so would require broader privileges than rotation needs, and a new user wouldn't inherit the grants your applications depend on. Instead, you create two users up front and name them in the rotation.

### Why two users?

Each cycle, Infisical generates a new password for whichever of the two users isn't currently active and maps it to your secrets. The other user's password stays valid as a grace-period credential until the following cycle replaces it, which is what gives the rotation its overlap.

Infisical changes passwords in place, so with a single user it would overwrite the credential currently in use and lock out every client still holding the old password. The cycle never needs more than two users, which is why the configuration form has fixed **Database Username 1** and **Database Username 2** fields.

### Who connects as the two users?

Your applications do. The pair backs one rotating credential: Infisical maps the active username and password to the secrets you choose, and your application connects as whichever user is currently active by reading those secrets.

Grant both users the same privileges, since either one may be the active credential at any time, and let Infisical be the only thing that sets their passwords. The one user you can't name is the one your [app connection](https://infisical.com/docs/integrations/app-connections/overview.md) authenticates with, because rotating its password would break the connection that performs the rotation.

### Rotating several credentials

Create a separate rotation for each credential you need, each with its own pair of users. A rotation produces a single active credential, so a database serving three applications that need independent credentials needs three rotations and six users. Two rotations must not share a pair of users, as each would overwrite the other's passwords.

If you want credentials issued per identity and revoked after a short lease, rather than one shared credential that changes on a schedule, use a [dynamic secret](https://infisical.com/docs/documentation/platform/dynamic-secrets/overview) instead.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.