How to choose tooling for non-human and machine identity security

where buyers go wrong

The most common mistake is buying a secrets vault when the real problem is that you cannot list your machine identities at all. A vault is useful: it stores and rotates credentials so they are not sitting in config files. But a vault only protects what you put in it. If you do not know how many service accounts, keys, tokens, and OAuth grants exist across your environment, the vault becomes one more place that holds some of them while the rest stay scattered. This trap catches small teams and large ones equally.

The second mistake is the opposite. Some teams discover the population, get alarmed, and buy a heavy posture platform before they have done the cheap, boring cleanup that would have cut the risk in half. Killing a hundred stale credentials and rotating the dangerous ones costs you time and no money. A platform bought before that cleanup spends its first quarter pointing at risks you could have removed for free.

The third mistake is treating agentic-AI identities as a future problem. They are already in your environment. Every AI agent that calls an API, reads a mailbox, or writes to a database does so with credentials. Those credentials are non-human identities, often provisioned fast by a developer testing something, often long-lived, and rarely owned. An agent also tends to hold broad, standing access so it can act across systems, and it acts without a human in the loop. That combination of wide reach and autonomy is exactly where the new risk concentrates.

The through-line across all three: inventory and the killing of long-lived secrets come before any platform. A tool sustains that work. It does not replace it.

before you evaluate: inventory and place yourself

Two pieces of work come first, and both can start this week.

Inventory the non-human identities. Pull the service accounts and app registrations from your identity provider, whether Microsoft Entra, Okta, or Google Workspace. Pull the IAM roles and access keys from each cloud account across AWS, Azure, and Google Cloud. List the OAuth grants and connected apps in your SaaS admin consoles. Find the CI/CD secrets and the credentials baked into pipelines. You will not get a perfect picture by hand, and that is fine. When you see your own ratio of machine to human identities, the rest of the decision gets easier.

Find the long-lived secrets. These are the static API keys, the passwords that never rotate, the certificates with multi-year lifetimes, the access keys a developer created in 2022 and forgot. Long-lived secrets do the most damage when leaked, because a stolen credential that never expires is a permanent door. Removing or rotating them is the single highest-return action available, and most of it does not require new tooling.

Then place yourself by size and cloud footprint. A lean team on one cloud with a dozen SaaS apps has a different problem than a group running three clouds, a large SaaS estate, and a growing fleet of AI agents. Your size sets how much manual work you can sustain. Your cloud footprint sets how fast the population grows and how spread out it is.

A practical way to run the first pass: give yourself a week, pull each source into one shared sheet, and tag every identity with three things you can see at a glance: its owner if you can find one, the age of its newest credential, and the breadth of its access. The orphaned, old, and over-permissioned rows are your starting work. Do this work first and you walk into vendor calls knowing your own numbers.

the category in depth

The market splits into overlapping categories. Understanding the overlap matters more than memorizing the labels, because vendors blur them on purpose.

Secrets management and vaulting. Stores, controls, and rotates API keys, tokens, and credentials so they are not living in config files or someone's laptop. Solves the scattered secret. You need it the moment you have more than a handful of credentials and any developer can read them in plaintext. The overlap: a vault holds secrets, but it does not find the ones you forgot to put in it.

Machine identity and certificate lifecycle management. Issues, tracks, and renews certificates. Solves the expiry outage. You need it once certificates are numerous enough that a spreadsheet and a calendar reminder stop being reliable. This is not rare: 72% of organizations had at least one certificate-related outage in the past year (CyberArk, 2025).

Workload identity. Instead of handing a workload a long-lived shared secret, it issues a short-lived, attested identity at the moment the workload starts. The open standard here is SPIFFE, with SPIRE as the common implementation. There is nothing long-lived to steal. You need it once you run dynamic workloads, containers, or services that come and go. The overlap: it reduces what a vault has to hold.

Non-human identity discovery and posture. The newer category, and the one most teams are missing. These tools find service accounts, keys, tokens, and OAuth grants across cloud and SaaS, then risk-rank them by access, age, and exposure. Solves the unknown population. You need this once the population is large, spread across multiple clouds and SaaS apps, and changing faster than a person can track. Discovery feeds everything else, because you cannot vault, rotate, or govern what you have not found.

CIEM, cloud infrastructure entitlement management. Right-sizes entitlements across your cloud accounts, including those held by machine identities. Solves the over-permissioned identity. You need it once your cloud footprint is large enough that entitlements have drifted past what anyone intended.

Service-account governance and rotation. Brings ownership, review, and rotation to accounts that never had an owner. Solves the orphaned account. You need it the moment you have service accounts with no named owner, which is to say almost immediately. It is discipline more than tooling, and the discipline is what turns a one-time cleanup into a habit.

A word on the newest members. Agentic-AI identities are non-human identities too, and they sit awkwardly across these categories. They use secrets, so a vault touches them. They hold entitlements, so CIEM touches them. They are discovered, so posture tooling should find them. But they behave unlike a normal service account, with broad reach and autonomous action, so a tool that treats them as ordinary will under-rate them. Test for it directly rather than assume coverage.

what is right for your size and situation

• Lean or small, one cloud, light SaaS · What you most likely need: Manual inventory, a basic vault, kill long-lived secrets · What you can defer: Posture platform, CIEM, dedicated owner
• Growing mid-market, one or two clouds · What you most likely need: Inventory that stays current, vault with rotation, start issuing short-lived credentials, certificate lifecycle if outages have hurt you · What you can defer: Full posture platform until the population outpaces manual work
• Larger or multi-entity, two-plus clouds · What you most likely need: Discovery and posture tooling, service-account governance, CIEM, a named owner for the program · What you can defer: Little, at this scale most pieces earn their place
• Enterprise or cloud-heavy · What you most likely need: Full machine-identity program, workload identity at scale, dedicated owner, automated rotation and remediation · What you can defer: Manual inventory as a primary control, it no longer scales

A few special cases cut across the table.

Multi-cloud. Running two or more clouds multiplies the discovery problem, because each cloud holds its own identities under its own model, and the cross-cloud trust paths are where access hides. Discovery breadth across all your clouds becomes non-negotiable sooner than headcount alone would suggest.

CI/CD-heavy engineering orgs. If your pipelines mint and consume secrets constantly, the credential population grows with every build. Workload identity and tight pipeline secret handling matter here even at modest headcount.

Teams deploying agentic AI. Once agents are acting in production, you need a tool that sees them and rates them honestly, plus governance over what access an agent is granted in the first place. This can pull a mid-market team toward posture tooling earlier than its size would imply.

sourcing models

Manual inventory plus a vault you run. You script the discovery against APIs you already have, store and rotate secrets in a vault you operate, and review on a cadence. Fits lean and small teams. Cheap, and it teaches you your own environment. It breaks down when the population outpaces the cadence.

A discovery point tool. A focused tool that finds and risk-ranks non-human identities without governing or remediating. Fits a team that has outgrown manual inventory but is not ready for a full platform. The limit is that it tells you what is wrong without fixing it.

A posture platform. A broader tool that discovers, scores, governs, and often remediates across cloud and SaaS. Fits larger and multi-cloud organizations where the population is large and changing faster than people can track. It earns its cost once manual work and point tools no longer keep up.

A managed service. An outside team that runs the inventory, the cleanup, and the ongoing posture. Fits organizations of any size that lack a dedicated owner and would rather buy the outcome than the tool.

decision criteria in depth

Score each candidate against these criteria. A simple scale works: 0 for absent, 1 for partial, 2 for strong. Weight the rows that matter most for your footprint.

• Discovery breadth · What to look for: Reads cloud, SaaS, on-prem, and CI/CD secrets · Why it matters: Gaps in coverage are exactly where exploited credentials live
• Rotates and remediates · What to look for: Closes risks rather than only listing them · Why it matters: A report leaves the work, and the risk, with you
• Agentic-AI and workload coverage · What to look for: Sees AI-agent credentials and short-lived attested identities · Why it matters: Tooling built before the agentic wave often cannot
• IdP and cloud integration · What to look for: Reads cleanly from Entra, Okta, Google Workspace, and each cloud · Why it matters: Without an owner and system tie-back, risk scores are guesses
• Data residency and EU · What to look for: Clear answer on where your inventory is processed and stored · Why it matters: A non-EU region with no clear basis is a problem your DPO raises
• Pricing model · What to look for: Predictable as your identity count grows · Why it matters: A young category prices in ways that surprise you at renewal
• Admin overhead · What to look for: How much ongoing tending it needs · Why it matters: A tool nobody has time to run becomes shelfware
• Vendor viability · What to look for: Funding, roadmap, customer base in a young category · Why it matters: A vendor that folds takes your coverage with it

Three rows deserve a note. Discovery breadth is the one to test hardest, because partial coverage looks complete in a demo. The rotate-and-remediate row decides whether you are buying a fix or a longer to-do list. And vendor viability deserves real weight, because non-human identity posture is a young category with many recent entrants, and you are betting on the vendor still being around at your next renewal.

how it is priced and the true total cost

Pricing comes in a few shapes, and the sticker is rarely the whole bill. Per-secret or per-identity pricing scales with your population, the very thing that grows on its own. Per-certificate pricing applies to certificate lifecycle tooling. Platform pricing charges a flat or tiered fee for the whole console, predictable but often priced for the high end of your bracket. Consumption-based pricing charges for what you discover, scan, or rotate.

The hidden costs are where budgets slip. Discovery breadth often sits behind add-on modules, so the price that covers your main cloud does not cover your SaaS grants or your pipelines until you pay more. Rotation automation carries a real cost in engineering time, because every rotation must be tested against production. And services, whether onboarding, tuning, or a managed layer, add a line nobody quotes in the first call. Ask for the all-in number at next year's projected identity count rather than today's, and ask which capabilities are base versus add-on.

how to run the evaluation

Start with a shortlist of two or three, no more. A young category rewards depth over breadth in evaluation. Send a short RFP built from the criteria above: ask each vendor to state, in writing, their discovery sources, whether they rotate and remediate or only report, how they handle agentic-AI and workload identities, where data is processed, and their full pricing at your projected scale.

Run a proof of concept with success criteria fixed before you start. Two tests carry most of the weight. First, point the tool's discovery at one cloud account where you already hold a known inventory, and compare. The gap between what it finds and what you know is the truest measure of the tool. Second, test a rotation in staging against a non-critical credential, and watch what it does to map dependencies and roll back. A tool that rotates blind in a proof of concept will rotate blind in production.

Then check references, and ask the uncomfortable questions. What did it miss. What broke. How did the price move at renewal. What does the vendor's support actually feel like when something goes wrong.

traps and red flags

Partial discovery. A demo finds the identities the tool is good at finding. The risk lives in the ones it misses. The only defense is to compare the output against your own manual inventory and stare at the difference.

A rotation that breaks production. Rotating a credential sounds safe until it rotates one that three undocumented services depend on. A tool that rotates without first mapping the consumers of a credential, or without a staged rollback, can cause the exact outage you bought it to prevent. Ask how it discovers who uses a credential before it changes that credential.

Agentic-AI blind spots. An agent holds broad, standing access and acts without a human in the loop. A tool that treats it as a normal service account will under-rate it. Test whether the tool flags an identity that has wide reach and acts autonomously. Half of organizations have already reported an incident or breach stemming from a compromised machine identity (CyberArk, 2025), and the agentic ones are the hardest to reason about.

A vault that becomes another unmanaged secret store. A vault only helps if secrets actually move into it and stay current. A vault that holds half your credentials while the rest stay scattered, or one nobody rotates after the initial load, becomes one more place to check.

where this maps to regulation

Two frameworks make this work less optional than it once was. Under NIS2, the access and identity controls an in-scope organization must put in place do not stop at human users. A service account or an API key with privileged reach is an access path, and the obligation to manage access covers it. Under DORA, financial entities face explicit expectations on access management and the integrity of their systems, and a long-lived machine credential with broad access is squarely the kind of risk those controls exist to address. Neither framework names machine identities in a separate clause; both extend identity and access obligations to them by plain reading. The machine population belongs inside the same access controls you are already building for people.

a sequenced path

Crawl. Inventory the non-human identities by hand. Find and kill the long-lived secrets. Put a basic vault in place and give every service account a named owner. This stage needs no platform and removes most of your immediate risk.

Walk. Stop the problem from growing. Start issuing short-lived, attested identities to new workloads so you stop minting permanent credentials. Add certificate lifecycle management if expiry outages have hurt you. Move from a one-time cleanup to a quarterly review with an owner accountable for it.

Run. Once the population is large, multi-cloud, and changing faster than people can track, bring in discovery and posture tooling, automate rotation and remediation, and right-size entitlements with CIEM. Dedicate an owner to the program. This stage is where a platform earns its cost, and not before.

where to start

Non-human identity security is mostly a visibility and hygiene decision that a tool can later help you sustain, however much it looks like a tooling decision. Get the inventory. Kill the long-lived secrets. Stop new workloads from minting permanent credentials. Then, and only then, decide whether the size and spread of your population has earned a platform.