Securing a Cloud Account You Did Not Open Yourself

Changing the password is the easy part and the least important. The credentials that survive a password change are what you need to find.

20 May 2026 3 min read

When you take over any cloud account — bought, inherited from a departing colleague, or handed over with a project — the instinct is to change the password and move on. That is the easy step and the least important one.

Cloud platforms are full of credentials that keep working after a password change: API keys, access keys, service account keys, app registrations with client secrets, personal access tokens. Until those are dealt with, the account is not yours alone.

The order that matters

Change the password to something long and unique, stored in a password manager.
Enable multi-factor authentication on the primary login.
Change the recovery email and phone number to ones you control, and confirm no other recovery method remains.
Enumerate and revoke every programmatic credential.
Enumerate and remove every additional user, role and service identity.
Turn on audit logging.
Set a spending alert.
Only then, deploy something.

Steps four and five are the ones people skip and the ones that matter. A password protects the console. An access key bypasses it.

Where the credentials hide, by provider

Provider	Look here	What it is
AWS	IAM → Users → Security credentials	Access keys, valid until deleted
AWS	IAM → Roles, and trust policies	Cross-account access you may not expect
Azure	Entra ID → App registrations → Certificates & secrets	Client secrets that survive password changes
Azure	Subscriptions → Access control (IAM)	Role assignments at subscription scope
Google Cloud	IAM & Admin → Service Accounts → Keys	Downloaded JSON keys, long-lived
Google Cloud	APIs & Services → Credentials	API keys and OAuth clients
DigitalOcean	API → Tokens	Full-power personal access tokens
Linode	My Profile → API Tokens	Personal access tokens
Hetzner	Project → Security → API tokens	Per-project tokens
Alibaba Cloud	RAM → Users → AccessKey	AccessKey pairs, root keys highest risk
Oracle Cloud	Identity → Users → API keys	API signing keys
OVHcloud	Account → API applications	Long-lived application credentials

Work through the rows for your provider before deploying anything. It takes fifteen minutes and it is the difference between control and the appearance of it.

Do not use the root identity for daily work

Every platform has a top-level identity that cannot be restricted: AWS root user, Azure Global Administrator, GCP project owner, Alibaba Cloud root account. Secure it with MFA, then stop using it.

Create a normal user or role with the permissions your work actually needs and use that. If those credentials leak, the damage is bounded. If the root credentials leak, nothing is.

Turn on the audit log

AWS — CloudTrail, enabled in all regions with a trail to S3.
Azure — Activity Log is on by default; export it to a Log Analytics workspace to retain it.
Google Cloud — Cloud Audit Logs; admin activity is on by default, data access is not.
Alibaba Cloud — ActionTrail.
Oracle Cloud — Audit service, on by default per region.

An audit log is how you answer “what happened” later. Enabling it after the fact tells you nothing about the past.

Check for resources you did not create

Before assuming an account is empty, look in every region, not just the default one. A forgotten instance in an unused region is both a cost and a security surface.

List running compute in all regions.
List storage buckets and check whether any are public.
List load balancers, static IPs and NAT gateways — these bill whether used or not.
Check scheduled tasks, functions and any automation that runs on a timer.
Check DNS zones for records pointing somewhere you do not recognise.

Set the money alarm early

Before you launch anything, create a budget alert at a threshold well under what you expect. It is free on every platform and it is the fastest way to learn that something is running that you did not intend.

Common questions

Does changing the password invalidate API keys?

No, on every major platform. Access keys, service account keys and app secrets are separate credentials with their own lifecycle. They must be deleted or rotated explicitly.

What if I delete a key something depends on?

On an account you have just taken over, that is usually the point — you want to know what breaks and rebuild it with credentials you created. If uptime matters, inventory first, then rotate one credential at a time.

Is MFA enough on its own?

For console access, it is a large improvement. It does nothing about programmatic credentials, which is why the key sweep matters just as much.

How do I know if a service account is legitimate?

Check its creation date and its permissions. Anything created before you took over, holding broad permissions, with a downloaded key, should be replaced with one you create.

Where to go next

For a deeper treatment of keys specifically, see API keys and secrets management. Account configurations across providers are on the cloud accounts catalogue, and support is on Telegram if you want to check something before ordering.

AWS Google Cloud Microsoft Azure