6.5 Service Accounts, Non-Human Identities, and Privilege Management

Governing Non-Human Identity

Not every identity represents a person. Modern environments use service accounts, machine identities, application identities, CI/CD pipeline identities, containers, serverless functions, managed identities, API clients, bots, scripts, robotic process automation accounts, network devices, and IoT devices. These identities may authenticate with passwords, keys, certificates, tokens, instance metadata, workload identity federation, or signed requests.

Non-human identities can be harder to govern than human identities because they may not have a manager, employment status, or obvious business owner. They are also tempting places to store broad permissions because applications need to keep running. A service account that can read every database, write to storage, and administer cloud resources may appear to solve deployment problems, but it creates a powerful compromise path.

The first control is inventory. The organization should know which non-human identities exist, what system owns them, who approves changes, which credentials they use, what permissions they hold, where secrets are stored, and when they expire. Unknown service accounts are like unmanaged administrator accounts. They may survive migrations, mergers, vendor departures, and application retirements.

The second control is least privilege. A workload should receive only the permissions needed for its function, in the environment where it runs, for the resources it must access. Development, test, and production identities should be separate. Read-only reporting jobs should not use write-capable credentials. A backup process may need broad read access but should be isolated, monitored, and protected from deletion or encryption abuse.

Secrets management is central to non-human IAM. Secrets should not be hard-coded in source code, scripts, container images, tickets, documentation, or local configuration files. They should be stored in approved vaults or managed identity systems, accessed at runtime, rotated on a defined schedule, and revoked when no longer needed. Rotation must be tested because fragile applications may break when a credential changes.

Privileged access management controls accounts that can administer systems, change security settings, view sensitive data, or bypass normal controls. PAM may include credential vaulting, checkout workflows, just-in-time privilege, session recording, command filtering, approval, and post-use review. The goal is to reduce standing privilege and create accountability for high-impact actions.

Just-in-time access grants privilege only when needed and often only for a limited time. A database administrator may request elevated rights for a maintenance window, receive approval, complete the task, and lose privilege automatically. This pattern reduces the time an attacker can exploit a compromised account. It also creates evidence linking the privileged action to a request, approver, and business purpose.

Privilege escalation risk includes both legitimate elevation and attacker abuse. Legitimate elevation should be controlled through workflows, policy, and logging. Attacker escalation may exploit weak permissions, misconfigured roles, token theft, vulnerable software, or excessive delegation. IAM teams should work with security operations to monitor unusual privilege grants, new credentials, role changes, and access to sensitive secrets.

Break-glass accounts are emergency accounts used when normal access paths fail. They are necessary in many environments because identity providers, MFA services, networks, or PAM tools can fail. They should not become everyday shortcuts. Break-glass credentials should be protected, rarely used, monitored in real time, documented, and reviewed after every use. The organization should periodically test that emergency access works without exposing it to routine abuse.

Cloud environments increase the importance of non-human identity. A cloud role attached to a compute instance, function, or container can access storage, secrets, databases, queues, and administrative APIs. Misconfigured trust policies may allow one workload to assume another role. Overbroad permissions such as wildcard actions or global resource access should be challenged. Cloud identity policy should be reviewed with the same seriousness as network firewall rules.

Privileged and Non-Human Access Checklist

• Assign a named human owner and system owner to every service, workload, and automation identity.
• Store credentials in an approved secrets management system or use managed identity where possible.
• Separate production and nonproduction identities, credentials, and permissions.
• Use scoped permissions, short-lived tokens, and just-in-time elevation for high-risk access.
• Monitor secret access, privilege grants, credential creation, failed authentication, and unusual API calls.
• Retire identities and revoke secrets when applications, integrations, vendors, or devices are decommissioned.

The governance point is that non-human identity is not an exception to IAM. It is IAM at machine speed and cloud scale. If a service account has no owner, no expiration, broad permissions, and a secret stored in code, the organization has accepted a hidden privileged access path. Least privilege, lifecycle ownership, and monitoring bring that risk back into management view.