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

# Key Rotation

> Rotate Nuvera API keys and signing keys without exposing old secrets

Rotate API keys on a schedule, after staff changes, after any suspected exposure, and before changing deployment ownership. Rotate the signing key when the partner private key changes or may have been exposed.

## Rotate an API key

<Steps>
  <Step title="Create a replacement key">
    Open the API application and choose **Create replacement key**. Nuvera returns a new one-time API key and marks existing active keys as expiring when a grace window is used.
  </Step>

  <Step title="Store the new key">
    Store the new key in the partner secret manager. Do not paste it into tickets, chat, docs, logs, proof artifacts, or screenshots.
  </Step>

  <Step title="Deploy the new key">
    Deploy the service with the new `x-api-key` value while continuing to sign requests with the current private key.
  </Step>

  <Step title="Verify production traffic">
    Confirm that successful REST requests are using the new key. Check last-used metadata in the application screen.
  </Step>

  <Step title="Revoke the old key">
    Revoke the old key after the new deployment is verified. If there is a suspected exposure, revoke immediately and redeploy without a grace window.
  </Step>
</Steps>

## Rotate a signing key

Rotating the signing key changes the RSA key pair used for the `Authorization` JWT.

1. Generate a new RSA private/public key pair outside Nuvera or in the browser.
2. Store the new private key in the partner key manager.
3. Replace the application signing public key in Nuvera.
4. Deploy the service with the matching private key.
5. Send a signed test request and verify success.
6. Remove the old private key from service configuration after rollout.

Nuvera stores only the public key fingerprint and public key PEM. Existing raw API keys and private keys are never displayed.

## Emergency disablement

If a partner service is compromised, disable the API application from the partner app or ask a Nuvera admin to disable it from the organization hub. A disabled application rejects authentication even when the API key and JWT are otherwise valid.

## Audit and rollback expectations

Application creation, permission changes, enabled/disabled state changes, signing-key replacements, key creation, expiring-key updates, and key revocations are recorded in audit history.

For rollback:

* If the new key is bad and the old key is still active or expiring, switch service configuration back to the old key and investigate.
* If the old key was revoked, create another replacement key and deploy it.
* If the signing key was replaced with the wrong public key, replace it again with the public key matching the private key currently deployed by the service.