How to Build a Non-Human Identity Security Strategy

Someone asked you for a non-human identity security strategy, and now you have a blank document open and three vendor guides in your browser tabs.

A non-human identity security strategy is the operating model that determines which machine identities you govern, who is accountable for each one, which controls apply at each privilege tier, and how you prove the program works. The document requires four decisions.

Every guide you have read has given you a control list you already accept: enforce least privilege, rotate credentials, and monitor for anomalies. Nobody disagrees, which is exactly why controls are not the hard part.

Decision rights are the hard part. These programs do not stall because someone forgot about least privilege. They stall the first time you propose disabling a production service account and nobody in the room can say who decides. That is the problem this article solves. You will leave with a scoping rule for what belongs in your program, a decision-rights model that names who owns and who revokes each class of machine identity, four controls worth running, a maturity model with testable exit criteria, and five metrics your board and auditors will ask for.

What a Non-Human Identity Security Strategy Includes

A strategy that does not resolve all four decisions remains a wish list with a cover page.

Scope

Which classes of machine identity live inside your identity program, and which belong to another team? Get this wrong in either direction, and you either drown in inventory or miss the identities holding real entitlements.

Ownership

Who is accountable for each identity, and who arbitrates when the team that created it disagrees with the team that governs it? This is the decision almost nobody writes down, and it determines whether anything ships.

Control

Which controls apply at each privilege tier, and where is standing access still acceptable? Not every service account needs just-in-time provisioning, and pretending otherwise burns your credibility with engineering in week one.

Evidence

What do you hand an auditor, how often do you generate it, and which source of truth produces it? If evidence is a quarterly export somebody assembles by hand, you have built a reporting chore instead of a program.

Scope and ownership receive the least attention in published strategy guidance, and they are also the two decisions that kill programs.

Common Non-Human Identity Security Challenges That Stall Programs

Non-human identity security programs rarely fail because of tooling.

The failure is organizational, not technical. Have this conversation with peers at any security conference and the same pattern surfaces: they know machine identities are a problem, they have a rough count, and nobody can name the person accountable for a given service account. Most teams have no written rule for how a machine identity gets created or retired, so there's nothing to enforce even when someone wants to act.

That's not a discovery gap. Any competent platform will inventory 40,000 machine identities inside a week. What no platform will tell you is who's allowed to revoke one.

Here is the pattern you will recognize. Discovery lands in month one, and the results are worse than anyone expected: thousands of accounts, hundreds with admin rights, and a meaningful share dormant for a year or more. You build the remediation list. Then you propose disabling a dormant service account attached to a production service. The owning engineer says it might break something, and there is no rule for what happens next.

The list stops moving. By month four, it is stale. By month six, the program is a slide in someone’s quarterly business review (QBR).

Three structural conditions cause this, and none of them is technical. Machine identities are created outside any request workflow, so there is no approval record and no requester to trace. That is how non-human identity sprawl compounds quietly, one unblocked deployment at a time. They have no leaver event because the project ends and the credential does not. No function owns them by default because engineering builds them, identity governs them, security carries the risk, and compliance inherits the evidence.

How to Scope Which Machine Identities Your Program Governs

Not every machine credential belongs in your identity program, and scoping in everything is how these programs collapse under their own inventory.

Draw the line at entitlements. Identities that hold grants to an application or data store belong in identity governance because they can be owned, reviewed, right-sized, and revoked in the same way as an employee’s access. Common non-human identity examples in this category include service accounts, OAuth applications and SaaS integrations, service principals and managed identities, robotic process automation (RPA) bots, and AI agents.

Credentials that are primarily cryptographic material belong somewhere else. TLS and mTLS certificates, signing keys, and ephemeral workload credentials issued through SPIFFE or an equivalent framework are public key infrastructure (PKI) and secrets management problems. They matter enormously, but they are a different discipline with different tooling and a different owning team. Your strategy should name those credentials and their owning team explicitly instead of quietly absorbing them.

The test is short enough to apply in a meeting. Ask: “What could this identity reach, and would an auditor accept a review of it?” If the answer identifies reviewable entitlements, the identity belongs in the identity program. If the honest answer is “It is a key, and the control is rotation,” the credential belongs to the secrets team.

Both failure modes are common. If you scope in everything, you produce an inventory nobody can act on, which is how you end up with a 40,000-row spreadsheet and no remediation. If you scope in only secrets, you miss every identity holding an entitlement, which is most of what will appear in your next audit finding.

Revisit the boundary quarterly. AI agents are already pushing it because an agent can acquire privilege at runtime through tool calls and OAuth flows, which means its standing entitlements understate what it can reach at any given moment.

Who Owns a Non-Human Identity and Who Can Revoke it?

An identity nobody owns is an identity nobody will let you revoke.

Every strategy guide on this topic says to assign ownership. Almost none separates the two roles that matter, and conflating them is why ownership programs produce a spreadsheet column instead of a decision.

The accountable owner is the person or team that knows what breaks if the identity goes away. The governing function runs discovery, sets policy, and executes revocation. These are rarely the same people, and writing both into your program document is one of the most useful actions you can take in week one.

In the table below, IAM refers to identity and access management, GRC refers to governance, risk, and compliance, and CI/CD refers to continuous integration and continuous delivery.

Now consider the hard case your program will encounter in month two: a dormant service account with admin rights to a production data store that was last used eight months ago. The owning team will not approve revocation because nobody can prove the change is safe, and the downside of being wrong is an outage.

Give that case a rule instead of a meeting. The owning team gets a fixed objection window, such as five business days. Disabling, rather than deleting, is the default action, so the change can be reversed in seconds if something breaks. Unresolved objections escalate on a timer to a named executive so that nothing sits open indefinitely. Write the window, the default, and the escalation path into the strategy document itself because deciding during an incident is deciding too late.

Orphans are more tractable than they look. The last committer, resource tags, cloud billing account, network flow data, and the team that owns the connected application will resolve most of them. The identities that survive all five checks are not dead ends; they are findings. An identity with production access that no method in your organization can attribute to a person is exactly the type of finding your chief information security officer (CISO) wants on a slide.

Non-Human Identity Security Best Practices That Carry The Program

Four controls do most of the work, and each one closes a failure mode you will be asked to account for in an audit.

Continuous discovery

Maintain one inventory that spans your identity provider (IdP), cloud accounts, SaaS applications, and on-premises infrastructure, including local and orphaned accounts. Refresh it continuously rather than scanning the environment before each audit. A quarterly scan describes an environment that no longer exists by the time you act on it.

Right-sizing against usage

Compare granted entitlements with what the identity has used, and then remove the difference. Overprivileged machine identities are a common finding in this category, and usage data turn least privilege from a principle into an action.

Credential lifetime reduction

Move standing, long-lived secrets toward short-lived credentials that rotate automatically, and stage the transition so production does not break. A key minted years ago and never rotated is likely to turn up in an incident report. Sequence the work by blast radius, and start where a failed rotation is recoverable.

Review and retirement

Certify machine access on a schedule, and disable an identity before you delete it. Improper offboarding is one of the most consequential gaps in this category because the account outlives the project, the vendor, and the person who created it.

Volume is what makes access reviews fail. Certifying every entitlement during every cycle at machine scale guarantees rubber-stamping. Reviewing only what changed since the last cycle is the difference between a review that finds something and a review that gets clicked through.

Map all four controls to the framework you already use, whether that is NIST CSF 2.0, SOX, or ISO 27001. You want one control set that satisfies several auditors.

Why Your NHI Strategy Should Not Take 18 Months

The instinct to treat a non-human identity security strategy as a new multiyear initiative is understandable, but it is also why many programs never ship.

Published roadmaps often call for twelve to eighteen months to reach mature controls. They structure the effort as a standalone program with its own budget line, tooling evaluation, and steering committee. That structure fails predictably. By month twelve, the inventory you built in month two is stale. The AI agents your engineers deployed in month six were never in scope. The executive who sponsored the program has changed roles. The dormant admin account you found on day one holds exactly the same standing privilege it held when you found it.

The alternative is not to move faster on the same plan. Most of the IAM tools and processes needed for non-human identity access management already exist inside a functioning identity program: an inventory, an ownership-attribution model, a least-privilege policy engine, a review cycle, and a revocation path. These tools and processes were built for employees, and they work for machines as soon as machines are in scope.

That reframes the strategic decision. It stops being “What do we build?” and becomes “What do we extend, and what do we scope out?” The first is a two-year capital project. The second is a quarter of work against infrastructure you are already paying for.

Set the first milestone accordingly: governed machine identities running in production within one quarter. The goal is not a completed rollout or a finished platform; it is real identities with named owners, right-sized entitlements, and an attached review cycle. Connection speed makes that milestone realistic, and the milestone is achievable at scale. ChargePoint connected Lumos to more than 100 applications in under three months and surfaced its unused and orphaned accounts in the process, closing the discovery-and-ownership problem this article opened with within a single quarter.

Judge any strategy against that standard. If the plan cannot produce a single governed machine identity in ninety days, it is not yet a strategy; it is a procurement schedule with a governance narrative attached.

How to Measure Your NHI Security Maturity

Maturity stages without exit criteria are too subjective to guide a program.

Every framework in this space describes stages, but almost none defines what it means to complete one. Here is a version you can assess yourself against in five minutes, with an observable condition for leaving each stage.

Most teams reading this are between the Unmanaged and Manual stages for machine identities while operating at the Automated stage or higher for employees. That gap has a cause worth naming. Employees generate joiner and leaver events from an HR record, and every piece of lifecycle automation you own is downstream of that trigger. Machines have no equivalent. Nobody files a termination for a service account.

The payoff arrives at the Automated and Autonomous stages, where standing privilege finally starts to move. Code42 cut long-standing privileged access by 67% on Lumos, which is the trajectory you are aiming for, and the reduction holds because policy keeps enforcing it.

Do not skip stages. Automating on top of an incomplete inventory automates the wrong population quickly and confidently, and you will spend the following quarter explaining why the numbers improved while the risk did not.

Five Metrics That Prove Your NHI Program is Working

Five metrics turn a machine identity program into something a board can fund and an auditor can accept.

Each metric exposes a specific weakness, which is what separates this set from a generic KPI list. Report all five as trend lines. A snapshot tells your board nothing about whether the program is working.

1. Discovery coverage

Discovery coverage is the share of your environments feeding the inventory. Target 100%, and be explicit about what is excluded because an unstated exclusion is how a gap becomes a surprise.

2. Ownership rate

Ownership rate is the share of in-scope identities with a named accountable owner. It is a strong leading indicator of whether the program will still exist in a year.

3. Standing privilege ratio

The standing privilege ratio is the share of machine identities holding permanent elevated access. It should fall every quarter because standing privilege is one of the largest multipliers on non-human identity threats that you can control directly.

4. Credential age at the 90th percentile

Report the tail, not the average. The average tells you that rotation is broadly working, while the tail tells you which credentials are likely to appear in a breach report.

5. Time to revoke

Measure time to revoke from the decision until revocation takes effect. This is one of the most important numbers during an incident, and it tells you whether your decision rights work in practice or only on paper.

Skip mean time to detect and mean time to respond here. They are security operations center (SOC) metrics that appear in every guide, but neither tells your board whether machine identities are governed.

Why Teams Use Lumos For Non-Human Identity Governance

With the operating model established, the next question is whether your existing platform can apply it consistently to both people and machines.

Four decisions and four controls describe the program, but something still has to enforce them after the meeting ends. That is the moment most teams start shopping for separate identity governance solutions for human and machine identities.

Lumos is built to make that purchase unnecessary. Machines land in the same inventory as your employees, inherit the same least-privilege policies, and move through the same reviews. This delivers the one-program model the article has described as a product rather than a whiteboard diagram.

Ownership assigned automatically

Ownership is the decision that stalls everything else, and by Lumos’s own count, 95% of non-human identities have no assigned owner. Each discovered machine identity is mapped to a human owner automatically using the same attribution signals your team would otherwise chase by hand. The “accountable owner” column in your program document is populated without a quarter of manual archaeology.

Discovery that reaches outside your IdP

Discovery runs continuously across identity providers, cloud infrastructure, and SaaS applications. It reaches the service accounts, agents, and workload identities that never touched your IdP, which are the identities carrying risk that nobody has examined. More than 300 integrations determine whether that inventory is complete or merely large.

Least privilege enforced against usage

Identity Security Agents analyze what each machine identity touches and then flag the permissions it holds but never uses. They recommend policy changes that remove those unused permissions, so right-sizing becomes a review-and-approve step. Standing privilege decreases on a schedule you set.

Reviews that cover machines and people together

Application owners see human and machine access side by side in one certification campaign. Within the review itself, they can revoke a dormant or over-scoped service account or rotate its credential without an intervening ticket. That is what keeps machine reviews from becoming a separate cycle nobody reconciles.

Outcomes you can report

The reported outcomes correspond to the metrics you would track anyway. They include full visibility into service accounts, agents, and bots; quarterly access reviews that run 70% faster; and 40% fewer IT access tickets. These are three of the five measures from the previous section, and the platform produces them without a quarterly assembly exercise.

Govern Non-Human Identities The Way You Govern People

You have automated your deployments, infrastructure, and employee lifecycle. The identities doing all that automating are the last population you still track by hand—in a spreadsheet, with no owner or leaver event.

That is the central non-human identity security gap: it is not a tooling gap or a controls gap, and eighteen months of program design will not close it.

Write down the four decisions and name who signs. Then implement those decisions in a platform that already governs both populations because the extension argument holds only when one platform carries humans and machines through the same lifecycle. Lumos is built that way: service accounts, OAuth applications, cloud roles, and AI agents land in the same inventory as your employees, inherit the same least-privilege policies, and move through the same delta access reviews. Reviewers see only what changed instead of reapproving thousands of unchanged entitlements. Pluralsight runs five times as many reviews in 40% less time under that model, and it did not have to establish a second program to get there.

Ninety days from now, you will have governed machine identities or another roadmap. Book a Lumos demo and start the clock on the first one.

‍