Service Account Security: Managing Non-Human Identities in Cloud Environments

Non-human identities (NHIs)—service accounts, API keys, OAuth tokens, and machine credentials—have become the primary attack vector in cloud environments. These identities now outnumber human users by 50:1 or more in typical enterprises, yet they receive far less security attention.

The statistics are stark: 85% of organizations experienced a breach involving NHI compromise in the past year. Unlike human identities with MFA, password policies, and user training, non-human identities often have static credentials, excessive permissions, and indefinite lifespans.

This guide covers how to secure non-human identities across cloud environments, from basic hygiene to advanced workload identity federation.

The Non-Human Identity Problem

Scale and Complexity

A typical enterprise has:

• Thousands of service accounts across cloud providers
• Tens of thousands of API keys and access tokens
• Secrets scattered across config files, environment variables, and vaults
• Complex machine-to-machine authentication relationships

Why NHIs Are Targeted

Long-lived credentials. Unlike session tokens that expire, many API keys and service account passwords never expire. A key leaked in 2020 may still work in 2026.

Overprivileged by default. Service accounts often get broad permissions "to make things work" during development, then keep them in production.

Limited visibility. Organizations track human logins but often miss anomalous service account behavior. NHIs don't have managers to report suspicious activity.

Distributed everywhere. Secrets end up in CI/CD pipelines, container images, config files, developer laptops, and chat logs—any of which can leak.

Types of Non-Human Identities

Service Accounts (Cloud Provider)

Identity objects within cloud providers for machine-to-machine authentication:

API Keys

Long-lived tokens for API authentication:

• Third-party SaaS API keys (Stripe, Twilio, Datadog)
• Internal API authentication tokens
• Webhook secrets

OAuth Applications

Applications that authenticate via OAuth/OIDC:

• GitHub Apps
• Slack integrations
• Azure AD enterprise applications

Certificates and Secrets

• TLS certificates for service authentication
• Signing keys for tokens and artifacts
• Encryption keys for data protection

Securing Cloud Service Accounts

AWS: IAM Roles Over Access Keys

Anti-pattern: Creating IAM users with long-lived access keys for applications.

Better: Use IAM Roles wherever possible:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "ec2.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

IAM Roles eliminate static credentials:

• EC2 instances assume roles via instance metadata
• Lambda functions have execution roles
• ECS/EKS use task/pod roles
• Credentials rotate automatically

When access keys are necessary:

• Set maximum age (90 days recommended)
• Automate rotation before expiration
• Monitor for usage anomalies
• Scope permissions minimally

Azure: Managed Identities First

Anti-pattern: Creating service principals with client secrets that never rotate.

Better: Use Managed Identities:

• System-assigned: Tied to resource lifecycle, automatically deleted
• User-assigned: Reusable across resources, independent lifecycle

# Enable system-assigned managed identity on a VM
az vm identity assign --name myVM --resource-group myRG

When service principals are necessary:

• Use certificate authentication over client secrets
• Set short credential expiration (6 months maximum)
• Implement automated rotation
• Apply conditional access policies

GCP: Workload Identity Federation

Anti-pattern: Downloading JSON service account keys for applications.

Better: Use Workload Identity:

• GKE Workload Identity: Pods authenticate as GCP service accounts without keys
• Workload Identity Federation: External workloads (AWS, Azure, GitHub) authenticate to GCP

# GKE Workload Identity annotation
apiVersion: v1
kind: ServiceAccount
metadata:
  name: my-service-account
  annotations:
    iam.gke.io/gcp-service-account: [email protected]

When keys are necessary:

• Download only when workload identity isn't possible
• Rotate every 90 days
• Store in Secret Manager, not code
• Disable unused keys immediately

Secrets Management

Centralized Secrets Storage

Store all secrets in dedicated vaults:

Cloud-native options:

• AWS Secrets Manager
• Azure Key Vault
• GCP Secret Manager
• HashiCorp Vault (multi-cloud)

Benefits:

• Centralized audit logging
• Access control and policies
• Automatic rotation support
• Encryption at rest

Secret Rotation Strategies

Automatic rotation: Configure secrets managers to rotate credentials on schedule:

# AWS Secrets Manager rotation example
import boto3

def rotate_secret():
    client = boto3.client('secretsmanager')
    client.rotate_secret(
        SecretId='my-database-password',
        RotationLambdaARN='arn:aws:lambda:...',
        RotationRules={'AutomaticallyAfterDays': 30}
    )

Dual-token rotation: For zero-downtime rotation:

1. Create new credential (both old and new work)
2. Update applications to use new credential
3. Verify new credential works
4. Delete old credential

Secret Scanning

Prevent secrets from leaking to code repositories:

Pre-commit scanning:

• Gitleaks
• TruffleHog
• detect-secrets

Repository scanning:

• GitHub secret scanning (automatic for public repos)
• GitLab secret detection
• Snyk Code

CI/CD scanning:

• Scan environment variables
• Check container images for embedded secrets
• Audit deployment configurations

Least Privilege for NHIs

Permission Analysis

Regularly audit NHI permissions:

AWS IAM Access Analyzer:

aws accessanalyzer create-analyzer \
  --analyzer-name my-analyzer \
  --type ACCOUNT

Azure AD Access Reviews:

• Review service principal permissions
• Identify unused permissions
• Recommend permission reduction

GCP IAM Recommender:

• Suggests permission reduction based on usage
• Identifies unused service accounts
• Recommends role downgrades

Just-In-Time Access

Implement dynamic credential provisioning:

• HashiCorp Vault dynamic secrets
• AWS STS temporary credentials
• Azure Managed Identity tokens
• GCP service account impersonation

Scope Limiting

Resource-based policies: Limit which resources NHIs can access:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::my-bucket/specific-prefix/*"
    }
  ]
}

Conditional access: Require specific conditions:

• Source IP ranges
• Time-based access
• Resource tags
• Authentication method

Monitoring and Detection

Baseline Behavior

Establish normal patterns for NHI activity:

• Typical API call patterns
• Source IP addresses
• Access times
• Target resources

Anomaly Detection

Alert on deviations from baseline:

AWS CloudTrail + GuardDuty:

• Unusual API calls from service accounts
• Access from unexpected locations
• Credential usage after deletion

Azure Sentinel:

• Service principal anomalous sign-ins
• Unusual application consent grants
• Risky workload identities

GCP Security Command Center:

• Anomalous service account usage
• Key exposure notifications
• Unusual resource access

Key Metrics to Track

Governance and Lifecycle

Inventory Management

Maintain comprehensive NHI inventory:

• Owner/team assignment for each NHI
• Business justification
• Expiration/review dates
• Dependency mapping

Lifecycle Processes

Creation:

1. Business justification required
2. Security review for high-privilege accounts
3. Least-privilege permissions assigned
4. Expiration date set

Review:

1. Quarterly access reviews
2. Permission right-sizing
3. Usage verification
4. Owner confirmation

Decommissioning:

1. Identify dependencies
2. Rotate consuming applications
3. Disable (don't delete immediately)
4. Delete after verification period

Ownership Model

Every NHI needs an accountable human:

• Application owners for app service accounts
• Platform teams for infrastructure credentials
• Security team for break-glass accounts
• Clear escalation for orphaned identities

Workload Identity Federation

The Future: Keyless Authentication

Workload identity federation eliminates long-lived credentials by federating trust between identity providers.

GitHub Actions to AWS:

- name: Configure AWS credentials
  uses: aws-actions/configure-aws-credentials@v4
  with:
    role-to-assume: arn:aws:iam::ACCOUNT:role/GitHubActionsRole
    aws-region: us-east-1

Azure to GCP:

gcloud iam workload-identity-pools create azure-pool \
  --location="global"

gcloud iam workload-identity-pools providers create-oidc azure \
  --workload-identity-pool="azure-pool" \
  --issuer-uri="https://sts.windows.net/TENANT_ID/"

Benefits of Federation

• No static credentials to leak
• Short-lived tokens (typically 1 hour)
• Leverages existing identity infrastructure
• Auditable through identity provider logs

Implementation Roadmap

1. Inventory current NHIs and their authentication methods
2. Prioritize high-privilege accounts for migration
3. Implement federation for CI/CD pipelines
4. Migrate workloads to managed/workload identity
5. Eliminate static credentials where possible
6. Monitor for credential usage patterns

Frequently Asked Questions

How do we find all our non-human identities?

Start with cloud provider IAM inventories (AWS IAM, Azure AD, GCP IAM). Add secrets manager contents, CI/CD configuration, and Kubernetes secrets. Use CSPM tools for comprehensive discovery. The initial inventory is always incomplete—plan for ongoing discovery.

Should service accounts have MFA?

Traditional MFA doesn't apply to NHIs since there's no human to provide the second factor. Instead, use: short-lived credentials, workload identity federation, certificate-based authentication, and conditional access based on source network/identity.

How do we handle break-glass service accounts?

Keep privileged accounts for emergency access but: store credentials in secure vault with break-glass procedures, require approval workflow for access, alert on any usage, rotate after each use, review necessity periodically.

What's the difference between service accounts and service principals?

Terminology varies by provider. AWS IAM users/roles, Azure service principals, and GCP service accounts serve similar purposes—providing identity for machines and applications. Managed identities (Azure) and IAM roles (AWS) are preferred over traditional service accounts.

How do we secure secrets in CI/CD pipelines?

Use native secrets management: GitHub Secrets, GitLab CI variables, Azure DevOps secret variables. Better: use OIDC federation to assume cloud roles without static secrets. Scan pipelines for accidental secret exposure.

Conclusion

Non-human identity security is arguably more critical than human identity security today. These identities have privileged access, never sleep, and don't respond to phishing training. Yet most organizations invest far more in human IAM than NHI security.

Start by gaining visibility into your NHI inventory. Migrate to dynamic, short-lived credentials wherever possible. Implement secrets management and rotation. Apply least privilege consistently. Monitor for anomalous behavior.

The ultimate goal is keyless—authentication via workload identity federation that eliminates static credentials entirely. This journey takes time, but every step reduces your attack surface significantly.

Part of the 30 Cloud Security Tips for 2026 series.