How to Score Identity Risk for Service Accounts: A Practical Model

To score identity risk for a service account, combine four measurable factors into a single weighted score: standing privilege (what it can do), credential hygiene (how well its secret is rotated and stored), exposure (how reachable and how widely its credential is distributed), and blast radius (what breaks or gets breached if it's compromised). Score each 1–5, weight them, and rank every non-human identity in your environment. This matters more than it used to: non-human identities — service accounts, API keys, AI agents — now outnumber human identities in most cloud environments, and they typically carry broader standing privilege with weaker rotation and monitoring than human accounts. That combination is exactly what makes them the highest-yield target for an attacker and the hardest thing to see in your identity inventory.

Why service accounts need their own risk model

Human identity risk models lean heavily on behavioral signals: unusual login times, impossible-travel geolocation, MFA prompts, session anomalies. Service accounts break most of those assumptions. A service account is supposed to authenticate from a server at 3 a.m., 10,000 times an hour, without a human present. You can't prompt it for MFA. It rarely rotates its password. It often holds a long-lived key that's been copied into three CI pipelines and a Terraform state file.

So the question "how to score identity risk for service accounts" is really "how do you assess risk when the account can't be interactively challenged?" The answer is to score the static and structural risk of the identity itself — its permissions and its credential lifecycle — rather than relying on runtime behavior alone. Behavior still matters (a service account suddenly enumerating IAM roles is a red flag), but it's the tiebreaker, not the foundation.

The four scoring dimensions, with weights

Here is a workable model you can implement against AWS IAM, Azure service principals, GCP service accounts, or Kubernetes ServiceAccounts. Score each dimension 1 (low) to 5 (critical), then apply weights.

• Standing privilege (weight ×3). Wildcard permissions (*:*, Owner, cluster-admin), the ability to modify IAM/RBAC, or access to production data stores score 5. Read-only access to a single non-sensitive bucket scores 1. Privilege to escalate its own permissions is an automatic 5.
• Credential hygiene (weight ×3). A static key older than 90 days with no rotation, stored in plaintext or an env var, scores 5. A short-lived token issued by a workload identity system (OIDC federation, IAM Roles for Service Accounts, GCP Workload Identity) that expires in minutes scores 1.
• Exposure (weight ×2). Credential distributed across many systems, present in source control history, or reachable from the public internet scores high. A credential injected at runtime into a single locked-down pod scores low.
• Blast radius (weight ×2). Cross-account or cross-tenant reach, access to secrets that unlock other identities, or control of production infrastructure scores 5. An isolated dev-only workload scores 1.

Total possible score is 50. Anything above 35 is a break-glass remediation candidate; 20–35 is a scheduled fix; below 20 is monitored maintenance.

A worked example

Take a CI/CD service account named ci-deploy-prod in AWS:

• Standing privilege: It has AdministratorAccess to push infrastructure changes → 5 × 3 = 15.
• Credential hygiene: A static access key, 400 days old, stored as a GitHub Actions secret → 5 × 3 = 15.
• Exposure: The key is used by every deploy pipeline in the org and appeared once in a committed .env before being scrubbed → 4 × 2 = 8.
• Blast radius: Admin in the production account with access to the KMS keys → 5 × 2 = 10.

Total: 48 / 50. This is a top-of-list identity. The remediation is obvious once scored: replace the static key with GitHub's OIDC federation into a scoped IAM role, strip AdministratorAccess down to only the services the pipeline actually deploys, and put the KMS access behind a separate, narrowly-scoped role. That one change drops credential hygiene to 1 and privilege to roughly 3 — cutting the score by more than half.

How authentication maps to your scores

Readers often ask what the five ways to authenticate an identity are, and how "validating a user's identity" (the term you're looking for is authentication) applies to accounts with no user. The five common authentication factors are: something you know (password/secret), something you have (a token, certificate, or hardware key), something you are (biometrics), somewhere you are (network/geolocation context), and something you do (behavioral patterns). Service accounts realistically use only two — a secret they know or a certificate/token they have — which is precisely why credential hygiene carries so much weight in the model.

The strongest posture is to move service accounts off "something they know" entirely. Workload identity federation lets a workload prove what it is (a specific pod, a specific CI job) and receive a short-lived credential in exchange — no stored long-lived secret to leak. In Kubernetes, this means using projected ServiceAccount tokens bound to a specific pod and audience rather than legacy long-lived secret tokens, and federating those to your cloud IAM so the pod never holds a static cloud key.

Protecting and hardening the high scorers

Once you've ranked accounts, the fixes fall into a repeatable sequence:

• Disable interactive login. Service accounts should never be able to log in like a person. In Active Directory, set the account so interactive and remote-interactive logon are denied via Group Policy (Deny log on locally / Deny log on through Remote Desktop) and mark the account for non-interactive use. In cloud IAM, don't attach console-access or assign human-oriented sign-in credentials to workload identities. In Linux, set the account's shell to /usr/sbin/nologin.
• Enforce least privilege. Replace wildcard grants with the specific actions and resources observed in access logs over a 30-day window. This directly attacks the highest-weighted dimension.
• Eliminate standing secrets. Migrate to short-lived, federated credentials wherever the platform supports it; where you can't, enforce automated rotation and store secrets in a vault, never in code or environment files.
• Scope and monitor. Restrict which source IPs or workloads can assume the identity, and alert on the anomalies that do matter for machines: new IAM/RBAC modifications, first-time-seen API calls, or use from an unexpected network.

Making it a repeatable program

Scoring once is an audit; scoring continuously is a program. Feed your IAM inventory, cloud access analyzer output, and secret-store metadata into the four-dimension model on a schedule, and track the aggregate score trend over time. The goal is a shrinking count of accounts above 35 and a rising share of workloads using federated, short-lived credentials. Because non-human identities already outnumber human ones and rotate less, this trend line is one of the more honest indicators of whether your identity program is actually improving.

If you want a fast starting point before building the full pipeline, PlayCISO's free Identity Risk Calculator walks you through these dimensions and returns a prioritized score for a sample of your accounts — a useful way to sanity-check your own weighting before you operationalize it.