Machine Identity Inventory Template

Machine identities are the non-human accounts and credentials that let software talk to software: service accounts, API keys, OAuth clients, X.509 certificates, SSH keys, cloud workload roles, bots, and increasingly AI agents. They usually outnumber human accounts and rarely have a joiner-mover-leaver process. You cannot rotate, right-size, or revoke what you have not inventoried.

This template is for IAM, platform, and cloud security teams. It also satisfies the spirit of CIS Controls safeguard 5.5, which calls for an inventory of service accounts with owner, purpose, and review date.

How to use this template

1. Create one row per identity in a spreadsheet or your CMDB.
2. Populate technical fields automatically from cloud IAM, your identity provider, secrets manager, certificate authority, and Kubernetes clusters.
3. Fill owner and purpose fields manually with each team, starting with production and the highest-privilege identities.
4. Review quarterly and whenever an owning team changes.

Identity fields

• □ Identifier: name, ID or ARN, client ID, or certificate serial number.
• □ Type: service account, API key, OAuth client, certificate, SSH key, cloud workload role, Kubernetes service account, bot, or AI agent.
• □ Platform and environment: cloud account, cluster, production or non-production.
• □ Purpose: the workload that uses it and why.
• □ Business owner and technical owner. Orphaned identities with no owner are the biggest single risk.

Credential fields

• □ Authentication method: static secret, key pair, certificate, or federated workload identity. Prefer short-lived federated credentials such as OIDC federation or SPIFFE identities.
• □ Where the secret is stored: vault, environment variable, CI variable, or source code.
• □ Created, last rotated, and expiry dates.
• □ Rotation policy and whether rotation is automated. NIST SP 800-57 gives guidance on key lifetimes.

Access and risk fields

• □ Permissions granted, and whether they match observed use.
• □ Data classifications reachable.
• □ Can it create identities or change IAM policy? That is a privilege escalation path.
• □ Last used date, which exposes dormant identities.
• □ Risk rating (low, medium, high) based on privilege and data reach.
• □ Logging and alerting coverage.
• □ Decommission trigger: what event retires this identity.

Example row

First actions after the inventory

• □ Disable identities unused for a defined period (for example 90 days) after owner confirmation.
• □ Replace static keys with workload identity federation wherever the platform supports it.
• □ Right-size permissions to observed use.
• □ Automate certificate issuance and renewal to prevent expiry outages.
• □ Alert on new high-privilege machine identities.

Common pitfalls

• A one-off spreadsheet that is out of date within weeks. Automate collection.
• Ignoring non-production, which often shares credentials with production.
• AI agents running under a human's account, which makes their actions indistinguishable from the person's.