Service Account Security Best Practices for Cloud Teams

The best way to secure service accounts is to avoid long-lived keys, give each application its own account with least privilege, and use temporary credentials where the platform allows. Then disable unused accounts, rotate what must stay, and log every use. Google Cloud and AWS both publish this guidance.

Key takeaways

• Treat service account keys as an exception, not the norm.
• One account per application, one key per machine if you must have keys.
• Remove default or broad roles like Editor.
• OWASP lists improper offboarding and long-lived secrets as top non-human identity risks.

What is a service account?

A service account is an identity for software, not a person. Google says service accounts "represent non-human users." OWASP groups these under non-human identities, or NHIs.

What are the main risks?

OWASP's Non-Human Identities Top 10 for 2025 names these risks, among others:

• Improper offboarding: accounts and keys not deactivated when no longer needed.
• Secret leakage: keys and tokens in unapproved places during development.
• Overprivileged identities.
• Long-lived secrets that never expire.
• NHI reuse: one identity shared across several apps, so one compromise spreads.
• Human use of NHI: people using automated identities for manual tasks, which weakens auditing.

What are the best practices?

1. Prefer temporary credentials. AWS says to require workloads to use temporary credentials with IAM roles, and Google recommends attached service accounts and Workload Identity Federation over keys.
2. Block key creation by default. Google suggests organization policy constraints, with exceptions for projects that cannot use a better option.
3. Use one dedicated account per application. Avoid default service accounts, which can carry broad roles.
4. Grant least privilege. Google advises against automatic role grants and says to use role recommendations to remove unused permissions.
5. Do not let people impersonate service accounts more privileged than themselves.
6. Keep keys out of source code, binaries and file systems. If a key reaches a repository, delete it in IAM as quickly as possible, per Google.
7. Rotate keys you manage, and disable unused ones. Use last used data to find them.
8. Wait before deleting a service account, because a new account with the same name does not inherit bindings.
9. Turn on audit logs for impersonation and token events.
10. Name accounts by purpose, and do not put infrastructure hints in the email address.

How do I find the accounts I already have?

Export the list from each cloud, then record an owner, purpose and last use for each.

# Google Cloud: list service accounts in a project
gcloud iam service-accounts list --project PROJECT_ID

# AWS: list IAM users that might hold long-term keys
aws iam list-users
aws iam list-access-keys --user-name NAME

Anything without an owner or recent use is a candidate to disable. Disable first, wait, then delete.

What about CI pipelines and secrets?

Pipelines are common holders of static keys. Replace them with short-lived federation where your platform supports it, and scan repositories for leaked keys. Try the demo to see how secrets scanning surfaces them.

Click through it at your own pace, or open it full screen.

See also best secrets management tools for startups.

Frequently asked questions

Sources

• Google Cloud, best practices for managing service account keys
• Google Cloud, best practices for securing service accounts
• AWS IAM security best practices
• OWASP Non-Human Identities Top 10, 2025

Last reviewed: 19 October 2026.