Machine Identity Management: A Practitioner's Playbook for Non-Human Identities

Quick answer: Machine identity management is the discipline of discovering, owning, credentialing, rotating, monitoring and retiring the identities used by software rather than people: service accounts, API keys, OAuth clients, TLS certificates, SSH keys, cloud workload identities and, increasingly, AI agents. In most enterprises these non-human identities (NHIs) now outnumber human identities many times over, and most have no owner, no expiry and no review. The decision rule: if an identity can authenticate, it needs an owner, a lifecycle and a log.

Three years ago, machine identity management was a PKI team's problem. Today it is the front line. The breaches that defined 2023 to 2025 (a stolen service account credential in a support system, an unrotated token reused weeks after the original incident, a legacy test tenant with an over-permissioned OAuth application, and a wave of data theft from cloud data platforms where accounts lacked MFA) were not failures of human authentication. They were failures to govern identities that nobody logged into.

This article is for IAM program owners, identity architects and security leaders who have been handed "non-human identities" as a 2027 objective and need a plan that survives contact with a real estate: thousands of service accounts, a dozen clouds and a vendor market that is still defining the category. It focuses on what to do, in what order, and how to measure it.

What is a non-human identity, and how is it different from a machine identity?

The terms overlap, and the industry has not settled them. In practice:

• Machine identity historically meant cryptographic identities for devices and workloads: X.509 certificates, SSH keys, and the keys that let machines trust each other.
• Non-human identity (NHI) is the broader, newer umbrella. It includes machine identities plus every account or credential that acts without a person present: service accounts in Active Directory and Entra ID, cloud IAM roles and managed identities, API keys, OAuth clients and tokens, CI/CD pipeline identities, bots, RPA accounts and AI agents.
• Workload identity is the cloud-native subset: a short-lived, attestable identity issued to a running process (for example a SPIFFE SVID or a cloud provider's managed identity) instead of a static secret.

The useful distinction for a program is not vocabulary. It is this: human identities have a lifecycle driven by HR events, while NHIs have a lifecycle driven by engineering events (a deploy, a new integration, a decommission) that IAM teams rarely see. That is why NHIs accumulate.

Why are machine identities the biggest gap in enterprise IAM right now?

Four forces have converged.

1. Volume. Vendor and analyst surveys consistently report that non-human identities outnumber human identities by an order of magnitude or more in large enterprises; the exact ratio varies by estate, but the direction is not in dispute. Every microservice, pipeline and SaaS integration adds identities faster than any access review cycle can absorb.
2. Standing privilege. NHIs are routinely granted broad, permanent entitlements because "the integration broke when we tightened it." Many hold admin-equivalent rights in cloud accounts, directories and data platforms.
3. No MFA, no expiry. Human accounts are now largely protected by phishing-resistant MFA and conditional access. Most NHIs still authenticate with a single long-lived secret, which is exactly what attackers harvest from code repositories, CI logs and compromised laptops.
4. Agentic AI. AI agents are NHIs that make their own decisions about which tools to call. They inherit every weakness above and add a new one: non-deterministic behavior. (We cover this class separately in AI agent identity: how to authenticate and govern agents.)

Regulators have noticed. DORA and NIS2 in Europe, APRA CPS 234 and CPS 230 in Australia, and NIST SP 800-207 (Zero Trust Architecture) in the US all expect access controls to cover "entities" and "subjects," not just employees. Auditors are starting to ask for service account inventories and ownership evidence.

What does the OWASP Non-Human Identities Top 10 tell you to fix first?

The OWASP Non-Human Identities Top 10 (first published in 2025) is the most useful vendor-neutral checklist available. Its categories map directly onto the controls below:

• Improper offboarding — What it looks like in your estate: Service accounts for departed vendors and retired apps still enabled · Control that addresses it: Ownership + decommission workflow
• Secret leakage — What it looks like in your estate: Keys in repos, CI logs, chat, wikis · Control that addresses it: Secret scanning + vault-only issuance
• Vulnerable third-party NHI — What it looks like in your estate: SaaS-to-SaaS OAuth grants with broad scopes · Control that addresses it: OAuth app governance and consent policy
• Insecure authentication — What it looks like in your estate: Static passwords on service accounts, no MFA equivalent · Control that addresses it: Move to certificates, workload identity, or vault-brokered credentials
• Overprivileged NHI — What it looks like in your estate: Roles with wildcard permissions "to be safe" · Control that addresses it: Entitlement right-sizing from usage data
• Insecure cloud deployment configurations — What it looks like in your estate: Hard-coded credentials in IaC and pipelines · Control that addresses it: OIDC federation for CI/CD; no static cloud keys
• Long-lived secrets — What it looks like in your estate: Keys and tokens with no expiry · Control that addresses it: Rotation SLAs by tier; short-lived tokens by default
• Environment isolation — What it looks like in your estate: Same NHI used in dev, test and prod · Control that addresses it: Per-environment identities
• NHI reuse — What it looks like in your estate: One service account shared by many apps · Control that addresses it: One identity per workload
• Human use of NHI — What it looks like in your estate: Engineers logging in interactively as a service account · Control that addresses it: Block interactive logon; PAM for break-glass

The order matters. Discovery and ownership come first because every other control depends on knowing what exists and who answers for it.

How do you inventory machine identities across clouds, directories and SaaS?

You cannot buy a complete inventory; you assemble one. A workable discovery plan pulls from five source types and reconciles them in a single system of record (your IGA platform, a CMDB, or a purpose-built NHI tool):

• Directories: Active Directory and Entra ID service accounts, app registrations, service principals and managed identities; look for accounts with "password never expires," no recent interactive logon and service principal names.
• Cloud IAM: AWS IAM users and roles, Azure managed identities, GCP service accounts, plus their access keys and key ages.
• Secrets and PKI: every vault, KMS and certificate authority, including the public TLS estate and internal CAs.
• SaaS and OAuth: third-party apps granted access to Microsoft 365, Google Workspace, Salesforce, GitHub and the like, with scopes and last-used dates.
• Code and pipelines: secret-scanning results from repositories and CI systems, which reveal identities that exist nowhere else.

Then enrich each identity with four attributes: owner (a named person and a team, never a shared mailbox), purpose (what it does and what breaks if it is disabled), privilege tier (does it touch production data, identity infrastructure or payments?), and credential type and age.

How often should service account credentials be rotated, and what should replace them?

The honest answer for 2027 is that rotation is the fallback; ephemeral credentials are the target.

Rotation SLAs by tier (a reasonable starting policy, adjust to your risk appetite):

• Tier 0 — Example: Identity infrastructure, domain admins' automation, CA keys · Target credential type: Hardware-backed keys, certificate auth, just-in-time via PAM · Max lifetime if static: 30 days
• Tier 1 — Example: Production data, payments, customer systems · Target credential type: Workload identity (OIDC/SPIFFE), vault-brokered dynamic secrets · Max lifetime if static: 90 days
• Tier 2 — Example: Internal apps, monitoring, non-production · Target credential type: Vault-issued secrets with automatic rotation · Max lifetime if static: 180 days

Two external deadlines reinforce the shift to short-lived credentials. The CA/Browser Forum has approved a staged reduction of public TLS certificate validity, stepping down from 398 days toward 47 days by 2029; manual renewal will not survive that schedule, so certificate lifecycle automation is now mandatory, not optional. And PCI DSS 4.0 made MFA for all access into the cardholder data environment a requirement from March 2025, which pushes teams to replace password-based service accounts in scope with certificate or token-based alternatives.

The preferred patterns, in order:

1. Federated workload identity. CI/CD jobs and cloud workloads obtain short-lived tokens via OIDC federation (GitHub Actions to AWS, for example) so no static cloud key exists to leak.
2. Platform-managed identities. Azure managed identities, GCP service account impersonation, AWS IAM roles for service accounts (IRSA). The platform rotates; you never see the secret.
3. Dynamic secrets from a vault. Database and API credentials generated per session with a TTL measured in minutes or hours.
4. Static secrets with enforced rotation. Only where the application genuinely cannot do better, and with the rotation automated and evidenced.

How is non-human identity management different from traditional IAM, and does IGA cover it?

Traditional IAM and IGA were built around a joiner-mover-leaver model fed by HR. NHIs break three of its assumptions:

• No authoritative source. There is no HR feed for service accounts. The authoritative source has to be constructed from engineering systems and attestations.
• No natural reviewer. Access certifications assume a line manager. For NHIs, the reviewer is an application owner who may not know what the identity does. Reviews must be usage-driven ("this role used 4 of its 212 permissions in 90 days") rather than entitlement-list-driven.
• Different failure cost. Disabling a stale human account annoys one person. Disabling the wrong service account takes down a payments batch at 2 a.m. Change windows, dependency mapping and reversible quarantine states are essential.

Most IGA platforms now market NHI governance, and several can ingest cloud identities and OAuth grants. Use them as the system of record and the campaign engine, but expect to add: secret scanning, a secrets manager or vault, certificate lifecycle automation, a CI/CD federation pattern, and detection content in your SIEM or identity threat detection and response (ITDR) tooling for NHI anomalies. The architecture question of how these pieces fit together is the subject of Identity fabric: what it is and how to build one.

How do you establish baseline behavior for machine identity monitoring?

Humans are noisy; machines are predictable. That makes NHIs the easiest identities to monitor well, provided you capture the right telemetry.

For each Tier 0 and Tier 1 identity, baseline over 30 days:

• Where it authenticates from (source IPs, VPCs, regions, workload attestation).
• When (service accounts have schedules; a nightly batch identity authenticating at 11 a.m. is an event).
• What it touches (APIs, scopes, tables, privileged operations).
• Which credential it presents (a new key ID or a certificate from an unexpected issuer).

Then alert on deviation, with special handling for three high-signal events: interactive logon by a service account, a new credential added to an existing identity (a classic persistence technique), and consent granted to a new OAuth application with broad scopes. Feed these into your ITDR or SIEM, and give them an owner who can act, because an NHI alert without a runbook is noise.

Measuring the program: five metrics that boards understand

Report quarterly on:

1. Percentage of NHIs with a named owner (target: 100% for Tier 0/1 within 12 months).
2. Percentage of Tier 0/1 NHIs using ephemeral or platform-managed credentials rather than static secrets.
3. Median credential age, by tier.
4. Count of NHIs with standing admin-equivalent privilege, trending down.
5. Mean time to revoke a compromised or leaked NHI credential (test it with a drill).

These sit naturally inside the broader program view described in IAM strategy: a maturity model and 12-month roadmap, where NHI governance is one of the domains that most often drags an otherwise mature program down a level.

Key takeaways

• Non-human identities now outnumber human identities in most enterprises and are the least governed part of the identity estate.
• Discovery and ownership come first; every other control depends on them. Quarantine, do not delete, until dependencies are known.
• Use the OWASP NHI Top 10 as the vendor-neutral control checklist and tier identities by privilege to set rotation SLAs.
• The target state is ephemeral, attested credentials (workload identity, managed identities, dynamic secrets), with static-secret rotation as the fallback.
• Machines are predictable, so baseline-and-deviate monitoring works well; feed high-signal NHI events into ITDR with runbooks.
• Report ownership coverage, credential age and standing privilege quarterly; these are metrics boards and regulators understand.

Join your peers at Identity World 2027

Identity World is the global identity and access management forum, built by practitioners for practitioners, with no product pitches on stage. Machine and non-human identity governance is on the agenda in every city: Sydney, February 18 · Melbourne, March 17 · New York, May 6 · London, June 16 · San Francisco, November 3.

Not ready to register? Sign up for updates and the IdentityBriefing newsletter.