# Rotate a credential

Source: https://opvs.ai/docs/guides/vendors/rotate-credentials

> Replace your partner key or signing certificate on a schedule or after a suspected leak, without downtime.

You hold two credentials, and each is replaced in its own way:

```
Partner key   ── mint new → switch CI → revoke old      (no downtime)
Signing cert  ── mint new → switch CI → re-sign → revoke old (no downtime)
```

Rotating a credential is not the same as pulling a package version. For that, see [Revoke a version](https://opvs.ai/docs/guides/vendors/revoke-a-version.md).

## When to rotate

**On a schedule.** Every 90 days is a sensible default for a partner key. The registry does not enforce expiry; neither credential expires on its own.

**Immediately when:**

- someone with access leaves your team;
- the credential appears in any log, screenshot, transcript or chat, even your own;
- a laptop or CI runner holding it is lost or retired;
- it landed in a `git push`, even if you rewrote history afterwards;
- OPVS tells you it may be involved in an incident.

If you are unsure, treat it as leaked. Rotating is cheap.

## Rotate a partner key

Keep this order and there is always one working key:

1. Write to vendors@opvs.ai: "Please mint a new partner key for `@yourvendor`, replacing the key starting `opvs_pk_xxxxxxxx`."
2. Receive the new key once, through the secure channel.
3. Put it in every CI environment that publishes.
4. Run a [dry-run publish](https://opvs.ai/docs/guides/vendors/preflight.md) and one real call from each environment to confirm it works.
5. Ask OPVS to revoke the old key by its prefix.

Revoking first would make any running publish job fail with `403`.

## Rotate the signing certificate

1. Ask OPVS for a **rotation** certificate for your vendor. You receive the new private key by a one-time link, as in [Your signing certificate](https://opvs.ai/docs/guides/vendors/signing-certificate.md).
2. Replace the key in your CI secrets.
3. Publish your next version; it is signed with the new key.
4. Ask OPVS to revoke the old certificate **only if it leaked**. Revoking a certificate disables installs of the versions it signed, so for a routine rotation leave the old one active until no workspace depends on those versions.

## If a key leaks

Act as soon as a leak is plausible, not when it is proven.

```
Minute 0   write to vendors@opvs.ai, subject "Credential leak — @yourvendor"
           say which credential, when you noticed, and where it was exposed
Minute 5   OPVS revokes it (a partner key stops working at once)
Minute 10  OPVS mints a replacement and sends it to you
Minute 15  you install it in CI and run a check call
Later      OPVS can give you an audit of activity made with the leaked key
```

Two things not to do in a hurry:

- **Do not just delete the key on your side.** That stops you using it; it does not stop anyone else. Only revocation by OPVS does.
- **Do not rely on rewriting git history.** Forks, CI caches and mirrors keep copies. Rotation is the only real fix.

## Audit

OPVS keeps the creation, last-use and revocation record of every key and certificate, including revoked ones. To ask for a report, write to vendors@opvs.ai with your vendor name, the time window, and what you need (mints, revocations, last use, publishes made with a given key prefix).