Human users are not the only identities in your cloud environment — and in most organisations, they are not even the majority. Service accounts, machine identities, and application roles often outnumber human users by a factor of ten or more. These non-human identities authenticate to cloud APIs, run automated workloads, and access sensitive data around the clock. When poorly managed, they become the most dangerous attack vector in your cloud estate.
This lesson explains what service accounts and roles are, why they present unique security challenges, and what governance frameworks executives should mandate to keep them under control.
Understanding Service Accounts and Roles
Service accounts are identities created for applications, scripts, and automated processes rather than for human users. Each major cloud platform implements them differently:
- AWS uses IAM roles for services, which provide temporary credentials through the Security Token Service. EC2 instances, Lambda functions, and containers assume roles to access resources without storing long-lived credentials.
- Azure provides managed identities (system-assigned and user-assigned) that automatically handle credential management for Azure services, plus service principals for applications that need to authenticate programmatically.
- GCP uses dedicated service accounts with key files or workload identity federation. Service account keys are long-lived credentials that require careful rotation and storage.
The critical risk with service accounts is that they often receive broad permissions during initial setup and are then forgotten. Unlike human accounts, they do not trigger password expiry reminders, are rarely included in access reviews, and operate continuously without the behavioural signals that help detect compromised human accounts.
Diagram
Service Account Lifecycle — Create, Assign, Monitor, Rotate, Retire
Circular lifecycle diagram showing five stages of service account management with security controls required at each stage.
Governance Framework for Non-Human Identities
Effective service account governance requires treating machine identities with the same rigor as human identities — and in some areas, greater rigor:
- Inventory and ownership. Every service account must have a documented owner — a human being who is accountable for its permissions, usage, and lifecycle. Orphaned service accounts with no clear owner should be flagged for immediate review.
- Least privilege enforcement. Service accounts should receive only the specific permissions required for their function. Avoid granting broad roles such as Owner or Administrator to any service account.
- Credential rotation. Where long-lived credentials are unavoidable, enforce automatic rotation on a schedule. Prefer short-lived credentials and federated authentication wherever possible.
- Activity monitoring. Monitor service account usage patterns and alert on anomalies — a service account that suddenly accesses resources outside its normal scope may indicate compromise.
- Regular reviews. Include service accounts in quarterly access reviews. Disable or delete any service account that has not been used within a defined period.
Action steps for your organisation:
- Conduct an inventory of all service accounts and machine identities across your cloud platforms
- Assign a human owner to every service account and document the assignment
- Identify service accounts with administrative or overly broad permissions and scope them down
- Implement credential rotation policies and migrate to short-lived credentials where possible
Quick Knowledge Check
- Why are service accounts often more dangerous than human accounts when compromised?
Because service accounts typically have broad permissions, operate continuously, are rarely included in access reviews, and lack the behavioural baselines that help detect compromised human accounts. - What is the advantage of short-lived credentials over long-lived service account keys?
Short-lived credentials expire automatically, reducing the window of opportunity for an attacker who obtains them. They eliminate the need for manual rotation and reduce the risk of forgotten, exposed credentials.