Identity & Access Control
Service account
A service account is a non-human account used by software, services, jobs, or automation to access systems or perform tasks.
In plain terms
A service account is a non-human login used by software and automation, not a person. These often have broad access and stale passwords, making forgotten service accounts a classic target.
Instead of relying on human credentials, applications and automated workflows use a service account to securely authenticate and interact with databases, APIs, and cloud resources. It gives software an identity that can be authenticated, authorized, monitored, and governed.
Service accounts are common in applications, databases, CI/CD pipelines, scheduled jobs, cloud workloads, monitoring tools, backup systems, and integration scripts. They often hold more durable access than human user sessions.
NIST SP 800-53 Rev. 5 identification, authentication, and access control principles apply to service accounts. Non-human accounts still need ownership, least privilege, lifecycle management, and audit evidence.
Authentication may use passwords, API keys, certificates, tokens, service account keys, managed identities, or workload federation. The method should match risk and avoid static secrets when a safer platform identity is available.
Authorization should be narrow. A backup service may need read access to specific data and write access to backup storage, but it should not receive broad administrator rights across the environment.
Ownership is essential. Every service account should have an accountable team, business purpose, application dependency, environment, and emergency contact. Ownerless accounts are hard to rotate or remove safely.
Service account credentials are frequent targets. Attackers search repositories, logs, configuration files, build systems, and compromised hosts for non-human secrets because they may bypass MFA and remain valid for long periods.
Managed identities and service mesh identities can reduce static secret exposure. They still require policy discipline, because a workload identity with broad permissions can be just as damaging as a leaked key.
Rotation should be planned. Long-lived service account keys should have expiration, automated deployment updates, and emergency revocation paths. Rotation that requires manual application changes is often delayed.
Interactive login should usually be prohibited. Service accounts should not be used by people for convenience, because shared non-human accounts destroy accountability and bypass normal user controls. Logging should show which service account acted, from which workload or host, against which resource, and whether activity matched expected behavior. Baselines help detect unusual use.
Access reviews should include service accounts. Reviewers need usage evidence, owner confirmation, and privilege details. A dormant service account with privileged access is a high-value cleanup target.
Lifecycle should follow the application. When an application, job, integration, or environment is retired, its service account, keys, roles, and trust relationships should be removed as part of decommissioning.
In practice, a service account is a machine identity with operational consequences. It should be treated as a governed identity, not as a hidden implementation detail in a configuration file.
The explicit failure mode is creating service accounts for convenience and never revisiting them. Over time, they accumulate broad permissions, stale keys, unknown owners, shared use, and missing logs. During an incident, responders may discover that the most powerful access in the environment belongs to software identities nobody actively manages. Mature service-account governance includes naming standards, owner fields, environment separation, least-privilege roles, key age, last-used evidence, allowed source workloads, and decommissioning triggers. Reviews should ask whether a managed identity or workload federation can replace static secrets. Monitoring should alert when a service account acts from a new host, calls unusual APIs, uses dormant credentials, or attempts privileged actions outside its normal schedule. These controls make software access accountable without forcing people to share or misuse non-human credentials. Service-account reviews should include both permission and behavior. An account may have acceptable permissions but operate from the wrong network, run at the wrong time, or access resources outside its purpose.
Secrets associated with service accounts should be rotated when owners change, applications are redeployed, or logs show unusual use. During decommissioning, teams should remove the account, keys, roles, scheduled jobs, and trust relationships together. Design should avoid one shared service account across many applications. Shared accounts make attribution weak, rotation risky, and incident response slow because defenders cannot tell which workload performed an action. Per-application or per-workload identity, scoped roles, and short-lived credentials make misuse easier to detect and contain. When shared accounts remain for legacy reasons, they should be documented as exceptions with a migration plan and compensating monitoring. Service accounts should also have clear environment boundaries. A development service identity should not read production data, and a production identity should not be reused in test automation. Environment separation limits mistakes and makes suspicious cross-environment activity easier to detect.