Should I delete old keys immediately after creating new ones?

No. Create the new key, update every consumer, confirm the consumer works, then deactivate the old key and delete it after a quiet period. Revoking first breaks whatever still uses the key. AWS supports an inactive state that is reversible, which makes the overlap safe.

How do I know which keys are still in use?

Use the provider's last-used data. The AWS IAM console shows when each access key was last used, and the Scaleway IAM section lists keys per user and application. A key used after you updated its consumer means something you have not found still holds it. Locate that consumer before revoking.

Does rotating keys replace changing the password and enabling MFA?

No, they are separate layers. The password and multi-factor authentication protect console sign-in. API keys, access tokens and SSH keys grant programmatic access that bypasses those prompts, so they must be rotated on their own. The security baseline after receiving cloud credentials covers both layers together.

Rotating API keys after an account change

Passwords get changed the moment control of a cloud account changes. API keys and access tokens usually do not, because they are invisible in daily use and nobody remembers where they are. Yet a long-lived key grants the same access as a login and never prompts for multi-factor authentication. This procedure rotates every credential type properly, whether the trigger is a legitimate handover, a departing team member or a routine schedule. AWS and Scaleway are used as examples because each has a clear identity and key model.

Table of Contents

Why rotation is not optional after a change

Any key issued before you took control may still be embedded in a script, a CI pipeline, a laptop or a third-party tool you have never seen. Changing the console password does nothing about that. The only way to be sure no previous holder retains access is to invalidate every credential that existed before the change and issue fresh ones under your control.

The same applies inside a team. When someone leaves or moves roles, their personal keys must go, and any shared keys they knew must be replaced. The security baseline after receiving cloud credentials places rotation in the first hour of ownership for exactly this reason.

Step one: inventory every credential

You cannot rotate what you have not found. Build a list of credentials by type:

Root or account-level keys. On AWS, access keys attached to the root user. These should not exist at all; if they do, deleting them is the first action.
User and service keys. AWS IAM user access keys, and Scaleway API keys, which are issued to IAM users and applications within an Organization.
SSH keys. Public keys stored in the provider console and injected into servers, plus authorized keys already on running machines.
Application secrets. Database passwords, object storage credentials and webhook tokens that live inside the platform.

Export the list from the console or API rather than relying on memory. On AWS the IAM console shows every user’s keys and their last-used date. On Scaleway, the IAM section of the console lists users, applications and their API keys. The last-used data tells you which keys are live and which are dead weight.

Step two: issue replacements before revoking anything

Rotation fails when a key is deleted before its consumer is updated, taking a pipeline or an application down with it. The safe order is: create the new key, update every consumer, confirm the consumer works, then revoke the old key. Both AWS and Scaleway allow more than one active key per identity, which exists precisely to support this overlap.

While you are issuing new keys, tighten scope. A key that only needs to read from object storage should not carry administrator rights. Scaleway’s IAM policies and AWS IAM policies both let you attach a narrower permission set to the new key than the old one had.

Step three: update every consumer

This is the slow part. Typical places a key hides:

CI and deployment pipelines and their secret stores.
Infrastructure-as-code tooling and any local state or variable files.
Configuration files and environment variables on servers.
Developer laptops and credential files in home directories.
Monitoring, backup and third-party SaaS integrations.

If your infrastructure is managed as code, this step is far easier because the consumers are declared in one place. The guide to infrastructure as code for a new cloud account covers keeping secrets out of that code in the first place.

Step four: verify, then revoke

Before revoking, check the last-used timestamp on the old key. If it was used after you switched consumers, something still holds it. Find that consumer before proceeding. When the old key shows no recent use, deactivate it first rather than deleting outright; AWS lets you make a key inactive, which is reversible if a forgotten consumer surfaces. Delete it after a quiet period.

Repeat for SSH keys: add your new public key to the console and to each server’s authorized keys, confirm access, then remove every key you did not issue.

Step five: record and schedule

Write down which keys exist, who owns each one, what it is used for and when it was last rotated. Then set a schedule. Quarterly rotation is a common starting point, tightened for high-privilege keys. Providers also let you set alerts on key creation and use, which turns rotation from a memory exercise into a monitored process.

The procedure is the same whatever the account’s starting state. Options listed on the Buy AWS Account page and the “Scaleway ID Verified+Card Account” on the Buy Scaleway Account page all arrive as accounts whose prior credentials must be assumed compromised until you have replaced them. The cloud account handover checklist lists rotation alongside the contact, billing and ownership updates that belong to the same event.