This is the first installment in a series about Non-Human Identities (NHIs) where I’ll use the Non-Human Identity Management Group’s Lifecycle Guide as the foundation. In this post, I’m focusing on the Joiner phase and sharing how I interpret the guidance through real-world experience, conversations with the IAM community, and a healthy dose of personal opinion.

The guide opens with a statement that immediately resonated with me:

“JML processes are typically quite weak in most organizations when it comes to NHIs. Static NHIs are created through many different and disparate provisioning processes, and in many cases, the credentials (e.g., passwords) are shared directly with the requestor of the NHI (i.e., a human), leading to broader issues around the inappropriate use of NHIs by humans.”

(I corrected their spelling of “organizations,” but otherwise left it intact.)

The amount of truth packed into that paragraph is hard to overstate, both from my own experience and from countless conversations I’ve had with people across the IAM community.

One thing that immediately stands out is how little consistency there is around the Joiner process for NHIs. (For now, I’m intentionally staying away from AI identities.) We don’t really have a common framework for the minimum amount of metadata that should exist before an identity is provisioned.

Imagine walking into HR and telling them you wanted a new employee’s workstation account created, but you didn’t know who they worked for, what department they belonged to, or what job they were doing. Nobody would accept that.

Yet we routinely create NHIs with about that much information.

The Minimum

At a minimum, I believe every NHI should have:

• Unique ID – The obvious one.
• Identity Type – Service Account, API Key, Certificate, Workload Identity, Robot, OAuth Client…whatever it actually is.
• Business Owner – The person accountable for the business function.
• Technical Owner – The person responsible for keeping it working.

This is where I see most organizations stop.

Unfortunately, this is also where the interesting work begins.

The next set of metadata is where your governance maturity starts to show.

• Application/System Association – Unlike people, you should know from day one exactly what systems an identity is intended to communicate with. Record every authorized relationship. If that list continues to grow, it’s probably time to ask whether the identity has become too broad and should be split.
• Business Purpose / Justification – What does it actually do? Make it understandable to anyone who reads it. Avoid vague descriptions. Wiggle room is your enemy.
• Expected Access – You should know what permissions it needs before it’s created. Ideally, that scope shouldn’t grow much over time.
• Provisioning Source – If you’re still provisioning manually like I am in many cases, I sympathize. If you’re using CI/CD pipelines, Kubernetes, Infrastructure as Code, or cloud automation, record where the identity originated. When identities can be created and destroyed in seconds, knowing where they came from becomes incredibly important.
• Creation Date – Everybody—and everything—has a hire date.
• Expected End or Review Date – Stop treating identities as something to be cherished forever. Make them easy to create through automation, easy to destroy when they’re no longer needed, and if neither is possible, make them easy to certify.

I think of this as a Minimal Viable Identity (MVI). I haven’t seen that term used elsewhere, so I may have accidentally invented it, but it captures the idea well: the minimum amount of information that should exist before an NHI is allowed to exist.

From MVI to FGI

Once you’ve established the minimum, the next step is moving toward what I’d call a Fully Governed Identity (FGI).

That includes metadata such as:

• Environment (Development, Test, QA, Production)
• Authentication method (Password, Certificate, Managed Identity, Workload Identity)
• Secret location
• Creation method
• Risk level
• Infrastructure location (AWS account, Azure subscription, Kubernetes cluster, network segment, etc.)
• ServiceNow request or change records
• CI/CD pipeline references
• CMDB relationships
• Privileged access indicator
• Regulatory scope (SOX, PCI, HIPAA, etc.)
• Owning team (Development and Agile teams often survive reorganizations much better than individual names.)

None of this metadata exists simply to satisfy auditors.

Every field should exist because some future automation, governance process, certification campaign, or decommissioning workflow will eventually depend on it. If humans are the only consumers of the metadata, you’re probably collecting too much—or collecting the wrong things.

Ironically, I think this is the easy part.

Research, conversations, real-world experience, and a little common sense can get you to a pretty solid list of metadata you should be collecting.

Figuring out where that information comes from, who owns it, and how you keep it accurate over time?

That’s where the wheels usually come off the bus.

That’s where I’ll pick things up in the next post.

In the meantime, I’d love to hear your thoughts. What metadata would you add? What have I overlooked?

• LinkedIn