> ## 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.

# Credential health

> Check on a schedule that the credentials stored for your PAM accounts still work.

A stored credential can stop working without anyone noticing. Someone changes a password directly on the target, an administrator disables an account, or a service principal's secret expires. Nothing tells Infisical, so the credential sits in the vault looking fine until a session fails or a rotation breaks.

Credential health checks each account on a schedule by signing in to its target with the stored credential, then records what happened. The check is read-only: it proves the credential still authenticates and changes nothing on the target.

## Concepts

Checking is configured on the [account template](/docs/documentation/platform/pam/templates/overview), which sets whether accounts are checked and how often. Every account created from the template inherits those settings. There is no per-account override, so accounts that need a different frequency belong on a different template.

Templates have checking on by default, every 24 hours.

### Statuses

An account's health is always in one of four states:

| Status          | Meaning                                                                        |
| --------------- | ------------------------------------------------------------------------------ |
| **Healthy**     | The target accepted the credential on the last check.                          |
| **Out of Sync** | The target rejected the credential. Sessions and rotation using it will fail.  |
| **Unreachable** | The target couldn't be reached, so the credential's state is unknown.          |
| **Unchecked**   | No check has run yet, or the account is missing the details needed to sign in. |

The account list shows a badge for **Out of Sync** and **Unreachable** only. A healthy account needs no attention, so it carries no badge.

## How it works

Each check signs in the same way a session would, using the account's own authentication method, and then disconnects. For most resources this means a login through the [gateway](/docs/documentation/platform/gateways/overview) that serves the account. Cloud accounts have no host to reach, so their check asks the provider for short-lived credentials instead.

| Account type                                     | What the check does                                                                                       |
| ------------------------------------------------ | --------------------------------------------------------------------------------------------------------- |
| PostgreSQL, MySQL, Microsoft SQL Server          | Signs in and runs a trivial query                                                                         |
| Microsoft SQL Server with Windows authentication | Completes an NTLM or Kerberos handshake                                                                   |
| MongoDB                                          | Signs in and pings the server                                                                             |
| Redis                                            | Sends `AUTH`, then `PING`                                                                                 |
| Windows Active Directory                         | Binds to the domain controller                                                                            |
| Windows                                          | Signs in over WinRM                                                                                       |
| Kubernetes                                       | Calls the API server and treats a 401 as a rejected credential                                            |
| SSH with a password or key                       | Signs in                                                                                                  |
| SSH with a certificate                           | Issues a certificate valid for 60 seconds from the account's certificate authority, then signs in with it |
| AWS IAM, GCP, Azure                              | Asks the provider for short-lived credentials                                                             |

Checks are spread across the interval rather than fired together, so a template with many accounts doesn't sign in to one domain controller all at once. Every check is recorded in the [audit log](/docs/documentation/platform/pam/auditing).

<Note>
  Microsoft SQL Server accounts using Windows authentication need a gateway running a version that supports the Windows authentication handshake. An older gateway reports these accounts as **Out of Sync** even when the credential is valid. Update the gateway to get an accurate result.
</Note>

## Configuring a template

Template settings are managed by a [Product Admin](/docs/documentation/platform/pam/concepts/access-control#product-membership). Go to **Privileged Access Management → Account Templates**, open a template, and find **Credential Health**.

Turn on **Check credentials** and set **Check every** to 1 hour, 12 hours, 24 hours, 7 days, or 30 days. Turning it off stops scheduled checks for every account on the template. Each account keeps the result of its last check, labelled as having been taken before checking was turned off.

## Viewing an account's health

Open an account and go to the **Configuration** tab. The **Credential health** section shows the current status, when the account was last checked, and when it was last healthy. When a check fails, the reason the target gave appears below.

Select **Check now** to run a check immediately. This requires permission to view the account's credentials, since the check signs in with them.

<Note>
  AWS IAM accounts store no credentials of their own, since Infisical assumes their role instead. They have no **Credential health** section and no **Check now** button. They're still checked on schedule, and their status appears as a badge in the account list.
</Note>

## When checking stops

A rejected credential takes the account off the schedule. Retrying a password the target has already refused is how a monitoring feature locks out a privileged account, so Infisical stops after the first rejection and waits for a person.

Checking resumes when you:

* Enter the credential again on the account.
* Select **Check now** and the check succeeds.
* Rotate the account, since [rotation](/docs/documentation/platform/pam/product-reference/credential-rotation/overview) verifies the new password before it commits.

An **Unreachable** account keeps being checked, because an unreachable target says nothing about the credential and retrying costs nothing.

Changing an account's host or gateway also pauses checking if you can't view that account's credentials, so the next check doesn't carry the stored credential to a target you just chose. The account's reason line says so, and entering the credential or running a check resumes it.
