If you haven’t read the past three articles, you probably should. They’re short.

NHI: The Teenage Years

NHI Lifecycle Management – Joiners

NHI Lifecycle Management – Joiners: Where Does the Data Come From?

At least to me, those were the easy parts. There wasn’t a lot of room for debate or question, which makes for a good ground floor.

But they leave some questions.

If the metadata doesn’t live in one place…

If ownership doesn’t belong to one person…

If the governance platform isn’t the authoritative source…

Who actually owns all of this?

It’s the answer every organizational leader hates:

Nobody owns all of it, because nobody actually creates all of it.

The application or service owner is accountable for why the identity exists and whether it should continue to exist. IAM owns the governance model. Source systems are authoritative for the facts they create. Platform teams own execution. And the governance layer brings the evidence together and detects when those truths stop agreeing.

So maybe this isn’t really an ownership problem.

Ownership just gets us into the discussion.

The real question is:

How do we know what we know about an NHI?

For every important fact, we should be able to answer:

• Where did it come from?
• Is that source authoritative for this specific fact?
• When did we last observe it?
• When was it last validated?
• What happens when another source disagrees?
• What action occurs when it becomes stale?

Not:

Bob owns the NHI.

And not:

IAM owns NHIs.

And definitely not:

ServiceNow owns the data.

The operating model looks more like this:

Why the NHI exists: Application/service owner
Whether it should continue existing: Application/service owner
NHI governance policy: IAM/Security
Data-quality rules: NHI governance/data stewardship
Application relationship: CMDB, application portfolio, or another authoritative application inventory
Actual identity existence: Native identity platform
Credential state: Vault/PAM/issuer
Actual permissions: Target authorization systems
Expected permissions: Policy, approved change, or IaC
Actual behavior: Logs/SIEM/runtime systems
Provisioning and deprovisioning execution: Native platform
Overall compliance decision: Governance control plane

That doesn’t mean the governance platform suddenly becomes the source of truth. It becomes the place where evidence is correlated, evaluated, and acted on.

Now we have to build the process that collects all of those answers.

That means a reasonable RACI—or at least a clearly defined group of stakeholders—that gets us to the people who can provide the answers, maintain the feeds, resolve conflicts, and agree on what happens when the data says something is wrong.

This is where spreadsheets start trying to sneak in.

We’ve got to resist that urge.

Spreadsheets can make a great visual and may even help us design the model. But if the operating process depends on people manually maintaining them, we’ve created an unmaintainable task that eventually nobody wants to do.

I’m going to leave this here for a bit and see what feedback it gets while I work around the spreadsheet trap.

I think the next article gets us out of the philosophical and ownership questions—I’ve answered those as much as I’m going to today—and starts moving toward the operational.

The doing.

What actually collects the data?
Where does it go?
Who makes sure the feeds work?
How often do we collect or validate it?
What controls prove any of this is actually happening?

Maybe that finally gets us to a durable identity record for NHIs before we move on from Joiners and start talking about Movers.