Service Account Security: A Practical Guide to Securing Non-Human Identities

Service account security is the practice of controlling, monitoring, and rotating the credentials used by non-human identities — software, scripts, and automated processes that authenticate without a person present. Securing them comes down to four moves: inventory every service account, scope each to least privilege, rotate or vault its credentials, and monitor its actual usage for drift. This matters more every year because, according to industry analysis, non-human identities now outnumber human identities in most cloud environments and typically carry broader standing privilege with weaker rotation and monitoring than human accounts — meaning your biggest identity attack surface is the one you're probably watching least.

What is a service account in cyber security?

A service account is a non-human identity used by an application, service, or automated process to authenticate and access resources — never by a person logging in interactively. Common examples:

• Cloud workload identities — an AWS IAM role assumed by a Lambda function, or a Google Cloud service account (the kind you create for a Gmail/Workspace API integration) that reads mailboxes or sends mail programmatically.
• API keys and tokens — a static key a CI/CD pipeline uses to push to a container registry.
• App-to-app accounts — a database login an application uses for every query, or a monitoring agent that pulls metrics across your fleet.
• AI agents — the newest category, often provisioned with broad read access to data stores and few guardrails.

The defining risk: service accounts usually have standing privilege (always-on access, not just-in-time) and no MFA, because no human is there to approve a prompt. That combination is exactly what attackers want.

How to tell if an account is a service account

You often inherit environments where human and non-human accounts are mixed together. Signals that an account is a service account:

• No interactive logins — authentication happens only via API, token, or key, never through a browser SSO flow.
• Naming conventions — prefixes like svc-, sa-, app-, or suffixes like @project.iam.gserviceaccount.com in Google Cloud.
• No MFA registered and no human owner in your directory.
• Machine-like behavior — identical requests at fixed intervals, access from server IP ranges, activity 24/7 with no weekend/holiday dip.
• Password or key never expires, or hasn't rotated in years.

In Active Directory, filter for accounts with a Service Principal Name (SPN) set or the DONT_EXPIRE_PASSWORD flag. In cloud, enumerate IAM roles and service accounts directly from the provider's API — don't rely on your SSO view alone.

How to tell where a service account is being used

This is the hardest and most-skipped step — and the reason so many stale, over-privileged accounts survive. You can't safely rotate or decommission what you can't trace. Practical methods:

• Read the logs, not the config. Query CloudTrail, Azure Sign-in logs, or Workspace audit logs for every event where the account was the actor. Look at source IPs, API calls, and resources touched over a 90-day window.
• Map last-used timestamps. AWS surfaces "last used" per access key and per IAM role; Google Cloud shows service account key usage in the IAM recommender. Any account unused for 90+ days is a decommission candidate.
• Grep your infrastructure-as-code and secrets stores. Search Terraform, Kubernetes manifests, and vault paths for the account name or key ID to find which workloads reference it.
• Use access-recommendation tooling. AWS IAM Access Analyzer and GCP's Policy Analyzer compare granted permissions against permissions actually used — the gap is your over-provisioning to trim.

How to secure a service account: a prioritized method

Don't try to fix everything at once. Prioritize by blast radius — privilege level multiplied by exposure — and work top-down:

• 1. Vault the credential. Move static keys and passwords out of code and config into a secrets manager (HashiCorp Vault, AWS Secrets Manager, GCP Secret Manager). Eliminate hard-coded secrets first — they're the easiest thing for an attacker to steal.
• 2. Scope to least privilege. Use the usage data from the previous section to strip unused permissions. A Gmail API integration that only sends mail does not need full mailbox read scope.
• 3. Replace static keys with short-lived credentials. Prefer workload identity federation, OIDC, or role assumption over long-lived keys. A token that lives 15 minutes is far less valuable stolen than a key that lives forever.
• 4. Rotate on a schedule and automate it. Any remaining static secret gets a rotation policy — 30 to 90 days — enforced by tooling, not calendar reminders.
• 5. Monitor for drift and alert.

  Ready to practise the decisions these articles describe?

  Run a free War Room →