This article continues the NHI discussion started in Part 1 by examining how non-human identities come into existence, operate, and are decommissioned. Just like human users follow Joiner-Mover-Leaver (JML) logic, NHIs follow their own pattern — one rooted in change management.

Lifecycle of NHIs

Just like human identities, NHIs have a lifecycle. Somehow, they come to exist, they have a life, and then they are destroyed.

For human identities, the human resource management (HRM) processes are the governing processes. Joiner–Mover–Leaver (JML) is the core model. Every Join, Move, or Leave event will be evaluated for the identity and access management consequences. If an actor joins an organization, a digital identity is created, and one or more accounts or usernames are assigned to this actor. Moving within the organization (to a new department or manager) will result in a reevaluation of permissions. And when leaving, all permissions will have to be revoked and licenses will be terminated, all to prevent the abuse of identities and identity theft.

For non-human identities, a different process is the governing process, not the JML processes. These processes are not HR processes. NHIs don’t apply for a job, nor do they drop out of the sky.

Before NHIs gain access to the network or a building, they must be onboarded. Meaning they should be identifiable as ‘trusted’ components that may get access for a defined purpose. A component has a purpose, a goal in non-human life. Be it a service, a server, a robot, Robotic Process Automation (RPA), or a machine interface. The component is implemented and configured for that purpose. The governing process is a Change Management process, and registration occurs in a configuration management database (CMDB). Reconfiguring the component to serve a different purpose or work in a different environment is possible, but that also requires a change. A financial reporting RPA will not become an invoicing RPA without reconfiguration, not without a change request. And removal of the component, again, takes a change.

So instead of JML, this is Create, Adjust, and Remove. We could refer to this as the CAR processes or, less specifically, change management.

Change Management

A change management process is more than just the Information Technology Infrastructure Library (ITIL) definition; it’s every change in an infrastructure or application landscape that results in functionality or features needed.

There is always a stakeholder who requests functionality: a tool, a service, or whatever. If the stakeholder has the mandate to do so, a change will be implemented, resulting in a component, service, or thing that can be used by or on behalf of the stakeholder. And, this is key: a change not only results in the component, but also in a governance item, typically the registration in a configuration management database (CMDB). And it is important that the CMDB item affected by the change has an owner and some more documentation, like the permissions needed by the component. We know who requested the component, we know its whereabouts, and we know the permissions.

Changing the functionality or location of the component is possible, but that, again, requires a change request and documentation. This is also valid for all components, including those built dynamically, such as services created in a CI/CD pipeline. The continuous process is a configured process; it has an owner, a build requester. So even those services and APIs are created in a structured and governed manner, and that again is a change management process. And even more, these processes can be part of automation (in CI/CD devops environments) or procurement processes. The changes (such as in the source code and config files) may even be documented in a version control system in highly automated build processes.

When the component is not in use anymore, it will be decommissioned, it must be disabled, removed, or destroyed. When the component has no purpose anymore, the final change is the removal of the component and registering the change in the CMDB. It must not be removed from the CMDB, because it once had its own identity, and for logging, monitoring, and forensics purposes, we need to know the history of the component.

Remember that maintaining the CMDB is an ongoing process; this precondition will not be discussed further.

As a further clarification, the digital identity lifecycle of non-human accounts, as defined in IDPro (see refs) is shown:

Figure 1: NHI lifecycle

IGA and Authorization

To automate the Human JML process, the supporting tool is an Identity Governance and Administration (IGA) solution. It evaluates the event in an HR system and, based on rules and roles, provisions accounts and authorizations to connected target systems. And after provisioning, it can also reconcile the target systems to validate accounts and permissions in these target systems. 

In this process, the IGA system will encounter accounts and authorizations that have not been generated by the IGA system. IGA will see the admin and root accounts that belong to the target system. These accounts are NHIs, and they exist as a part of the target system. If you implement a new Linux or Windows server, the root or admin account already exists. And, as you will understand, these new servers are the result of a change management process; it’s not a JML event. 

After reconciliation (the process of reading back the identity and authorization repositories of a target system), an IGA system will see the root or admin account in the target system, and that’s it. No need to manage admin or root as these accounts have all permissions, as they should have. They will not be related to a human identity. The account belongs to the component, and it also has an owner: the owner of the component. IGA will see the account and report it as ‘not being managed by IGA’, but that’s okay. In most IGA solutions, this type of account can be classified as a system account or service account. In fact, IGA solutions should enable it to be classified as an NHI.

In short, IGA takes care of human access as a result of the human JML process. But where does that leave the NHI’s, how should we manage their lifecycles? 

For human identities the lifecycle management process is well defined and IGA systems are well equipped to support that with both account management and role based access control, provisioning and deprovisioning accounts and authorizations. Can the same system also support NHI’s? And then my opinion is that IGA systems should not be the solution to manage the lifecycle of NHI’s. And there are multiple reasons for that. First, there is not just one process responsible for managing NHI’s. 

If you treat an NHI as a human identity, some additional controls are inevitable: If you would manage the lifecycle and authorizations of an NHI in en IGA solution, then these effects would be caused by the IGA solution:

• An account is created in the target system through the provisioning process;
• In the organizational structure of, not sure, either the org top level structure, or a sub level of the top level, to be defined by the owner? Or Manager or operator?;
• The birthright authorizations will be granted for the org top level;
• The line manager will see the NHI to grant authorizations by assigning a role.

But these provisioning effects have to be undone, because other controls and measures are already in place:

• Account creation has already been done by onboarding the NHI in the network;
• There is no need to assign the NHI to an organizational level: in the CMDB or change request the whereabouts of the component is already known;
• The NHI shall not have default birthright authorizations or roles, components don’t need birthright authorizations, they only need ‘least privilege’ access;
• The NHI doesn’t need a role, it has all the required permissions defined/described in the change. An RPA cannot just get new authorizations by changing the business role in IGA, it needs new functionality, because of the change.

And the same will happen for other NHIs: say we configured an RPA. Every day after office hours the RPA will read the sales figures, analyse the data, create a report and send the report to the head of sales. This RPA needs an account, authorisations, and resources to perform these actions. All of this will be configured while creating the NHI. 

The NHI will work on behalf of the Head of Sales, but it should not have the authorizations of the Head of Sales. Nor shall it have the business role of the Head of Sales, it only needs the permissions needed to read, analyze, create, and distribute the report. Least privilege. The permissions are very specific. Any other RPA will have different authorizations, no need to make a role for it. Its authorizations are a dedicated, non-reusable set of permissions. And these permissions will not be changed, unless the functionality of the RPA must change, in which case it will be newly developed. RBAC? No way! In fact, if you try to give a role to an NHI, you misunderstand the concept of RBAC… There are better solutions for managing access for NHI’s, like Policy Based Access Control or Relation Based Access Control to add the dynamics required. We will get to that in the next articles in this series.

Life Cycle Conclusion

NHIs don’t join the organization. NHIs are managed through a change management process. This means that an IGA solution does not fit the NHI lifecycle management process. IGA vendors may tease you in managing NHIs in IGA, but that’s not a sustainable solution.

NHIs must be managed in a change management process, and they should be registered in a CMDB and assigned to an owner.

Reality check

No, this hardly ever happens. In most organizations any CMDB is not reliable, the registration is, therefore, unreliable. But that should not keep you from managing NHIs in a controllable way. This is a call for fine-tuning the change management and asset management processes.

The organization may decide to implement specific tooling for managing NHIs, that’s all right, but that does not mean that the governance problem can be ignored. There must still be a business owner who is accountable for the life cycle and the authorizations granted. And just implementing additional tools next to the CMDB and service management solutions that are in place could only obfuscate the problem of lack of governance.

Conclusion

This lifecycle perspective underlines one essential truth: NHIs are governed through change, not employment. The Access article examines how these identities interact with systems. Specifically, how access “to” and “by” NHIs should be understood and controlled.

References

There are great resources that cover NHIs, but the lifecycle covered in this article are not clearly identified. Anyway, please study these articles in the IDPro Body of Knowledge:

• IDPro: Non-human account management: https://bok.idpro.org/article/id/52/ 
• IDPro: Digital Identity Lifecycle: https://bok.idpro.org/article/id/31/ 

The CAR case was invented by my colleague Henk Marsman, feel free to use CAR

Disclaimer: The views expressed in the content are solely those of the author and do not necessarily reflect the views of the IDPro organization.

About the author:

André Koot is principal IAM consultant at Dutch IAM consultancy and managed services company SonicBee (an IDPro partner). And member of the Advisory Board of IdNext.eu. He has over 30 years of infosec experience and over 20 years of experience as an IAM expert, acting as architect, auditor and program lead. For the last nine years he has taught a 4-day IAM training course. André contributes to the IDPro BoK as committee member, author, and reviewer.

The post Understanding Non-Human Identities (NHI) Part 2: Lifecycle appeared first on IDPro.

• An executive reads something or talks to a colleague about where the industry is heading.
• A leader comes back from a conference energized about “the next big thing.”
• The business needs to streamline how they work or unlock revenue.
• An IAM team member calls out something that obviously needs improvement.

I won’t say the list is in priority order… but it’s close.

And more importantly: that’s just how the idea arrives—not how it gets funded, approved, or actually done.

So how does something move from idea into reality?

IAM Project Momentum Model — Reference Card

1. Policy

Does policy already support the need?

If yes → you have built-in leadership intent.

If no → clarify policy language so the need becomes undeniable.

Momentum Source: documented executive stance + audit alignment.

2. Process

Where is the process failing, outdated, or not meeting policy intent?

Look for gaps caused by new technology, business changes, or legacy workflows.

Momentum Source: operational inefficiency + risk mitigation.

3. People

Do you have the skills today to execute the project?

If not, can training or restructuring solve it?

Leadership rarely hires for future problems—scope realistically.

Momentum Source: team capability + future-proofing.

4. Tools

Tools come last—after policy, process, and people are aligned.

Ask: does the tool meet policy needs, fix process gaps, and elevate skills?

Momentum Source: accelerators, not the foundation.

“The strongest IAM projects build momentum in this order:

Policy → Process → People → Tools.

Skip the order, and momentum breaks down.”

Momentum: The First Gate

A project needs momentum. It has to catch a wave, or roll downhill like a snowball.

Your position in the hierarchy determines how easily you can create momentum, what tools you have, and how much help you need.

Executives and senior leaders have experience (also called trial and error). They know the fastest path, they know who to talk to, and they’ve built trust. They still have to check the boxes to activate a project, but they get flexibility because leadership assumes they’ll finish the details. It’s basically a good line of credit.

The business or IAM staff?

We have more obstacles. Our job is to earn momentum. One way is getting buy-in from those executives and leaders—turning your idea into their idea.

But how?

By showing your work clearly.

1. Policy: The First Source of Natural Momentum

Ask first: does policy already support this?

If yes, you have documented leadership intent behind you.

If not, your first job is clarifying the policy so the need becomes unavoidable. If audits or controls testers are already raising concerns, momentum is forming all by itself.

2. Process: The Second Momentum Check

If policy is solid, look at where the process fails:

• Outdated workflows
• Gaps caused by evolving tech
• Steps stuck in “the way we’ve always done it”

If the policy is still valid but the process is behind, you have a legitimate need to drive change.

3. People: The Hardest Momentum to Build

Skill gaps matter. You can’t build a project the team has no ability to execute.

Sometimes you can train.

Sometimes you need restructuring.

Sometimes you have to scope the project down until hiring or attrition lets you rebuild the skills you’ll need later.

Leadership rarely hires for a future problem—so break the work into achievable phases and plan ahead.

4. Tools: Everyone’s Favorite Step (Which Should Be Last)

Tools get the attention because they’re exciting and vendors are loud. But tools must match the needs you discover in the first three steps, not the other way around.

When evaluating tools, ask:

• Does it meet policy intent?
• Does it modernize or fix process gaps?
• Does it bridge skills or provide a path to grow them?
• Is the vendor stable, innovative, and able to deliver on time?

Tool selection should be the result of the earlier steps—not the beginning.

The Real Momentum Curve

Working from Policy → Process → People → Tools gives you the strongest possible foundation.

The common trap is gaining just enough momentum to start and then stopping. That’s how projects lose funding, lose leadership attention, get paused, get mothballed, or get handed to people who don’t share the original vision.

A year later you find yourself asking, “How did this happen?”

Disclaimer: The views expressed in the content are solely those of the author and do not necessarily reflect the views of the IDPro organization.

Chris Power is an IT leader with over 25 years of experience across infrastructure, application delivery, and enterprise systems, with the last five years focused on Identity and Access Management. He currently serves as Senior Manager of IAM Operations at Sallie Mae, where he leads teams responsible for delivering and governing workforce identity services in a highly regulated financial environment.Chris focuses on building IAM programs that work at scale—balancing control, usability, and operational sustainability. His leadership perspective centers on daily workforce provisioning, access governance, and the automation required to support growing organizations without increasing risk or operational drag. He is particularly interested in how clear ownership, decision rights, and accountability models shape successful IAM outcomes. He writes and speaks from the perspective of a leader who has spent decades running systems and teams, and now applies those lessons to building resilient, auditable, and people-centered identity operations.

The post The Real Lifecycle of IAM Projects appeared first on IDPro.

However, this is explicitly not about user accounts and what some may call “digital identities”. It’s also not about non-human identities (NHIs), workload, service, machine-to-machine, or customer accounts. 

There are a lot of great articles already written on each and every one of these identity types by thought leaders, so I’d like to address the neglected others.

So, if this article is about identities, but none of the above, then what’s this article about? This is about other constructs that are fundamental to all Identity and Access Management programs, and to their related tools and applications. I’m referring to the identities of constructs like groups, applications, policies, networks, etc.

Identity Constitution

Allow me to simplify the constitution of ‘Identity’ into having three parts: 

1. An identifier (as unique as possible)
2. Attributes, which provide further differentiation, context, etc.
3. Relationships (e.g., “belongs to”), which can be documented as part of #2

“My dog’s name is Lola” ← These five words already encompass the three parts above:

1. Her identifier: Lola
2. Attributes: type: Dog
3. Relationships: owner: Me (although, if Lola could talk, she’d tell you her human is my wife)

An example of a non-living object is “my lucky t-shirt”. I’ve had this t-shirt for years, and it’s green, and it has a print of mountains with “Colo ‘rad’ o” written above (I’m a dad, I love it). At home, I may say, “have you seen my lucky t-shirt?”, and in the context of my family, chances are they’d know which one I’m talking about. If my daughter is not sure which t-shirt I’m talking about, she may ask, “what color is it?” (It’s green, an attribute). Life gives us an extensible schema to define any number of attributes to identify objects.

In the examples above, I shared the ‘Identities’ of two objects. The point is to ‘identify’ them.

If we turn to IAM-related objects, we can look at groups as in immediate need of proper identification. A group’s system identifier may be “xyz123”, attributes may include Group Name = “App X Users” (this may be considered the identifier, to the human eyes at least), and Group Description = “Accounts with access to App X”. Is this sufficient? Perhaps initially you’ll think “absolutely”. I’d argue that there’s a rich group identity hidden behind the ID, Name, and Description for this group. 

The IAM systems I’m most familiar with allow me to define a rich, extensible schema for accounts with many different attributes and even different attribute-types (string, Boolean, array, etc). This is excellent and much needed. In the last few years, the ‘group schema’ became available, so I may now define a Boolean value ‘For SSO’, ‘For SCIM Provisioning’, or ‘For Policy’. In addition, I want to define ‘Pushed to App’ as a Boolean value, and if TRUE, then ‘App’ (string type, as I can’t define an App object relationship).

But, there’s no extensible schema for ‘Apps’, or for ‘Group Rules’, or ‘Policies’, or ‘Networks’, etc. Lots of opportunities here to elevate the schemas of other objects to a whole new level. 

The CMDB is an Identity Management system

It follows that the system of record for constructs such as applications, systems, and perhaps groups is actually an IAM system, but for constructs other than accounts.

A proper CMDB will contain the creation date for any of its configuration items (CIs), its reason for being, its location, and, importantly, its relationships to other CIs.

A Source of Truth

One way to make your IAM system compliant and elevate its security is to delegate account creation to the correct source of truth. HR-driven provisioning is one example of this. If the IAM system delegates employee account creation to a correlated HR record, and the permissions to create accounts are removed from humans, a bad actor would have to shift their tactics to the HR system in order to create an account, which would likely require creating a role requisition, an applicant account, and then a hire/onboarding process.

Similarly, if the base attributes for a group, application, or other IAM construct are established and properly governed by the right source of truth, then the entire identity fabric will be more secure and compliant, but it’ll be like a self-maintaining organism, keeping the parts that are needed and auto-shedding those that have come to the end of their useful existence. 

Naming Conventions Don’t Work

You’ve likely implemented or have seen many naming conventions implemented to address this very topic. In my experience, a naming convention typically encodes attributes into the name (perhaps into a `Description`) with the intent to give more context to the object. This may work in some situations and it may help humans visually inspect the object. The problem begins when these existing encoded dimensions change or no longer capture the entirety of the object’s schema. When faced with this challenge, proper hygiene means renaming all existing objects, or, in the more common scenario, breaking the naming convention altogether. The end result is heterogeneous names and paralysis due to confusion and the need to research.

Suggested Actions

If you have access to an extensible schema for your objects, use it. Give those objects a rich identity that empowers a complete lifecycle of the object, from creation to decommissioning.

In the case of our Lola, she has her tag on her collar with her name and our cell phone numbers. However, she also has a microchip that extends the schema of her attributes to include our details, her vaccinations, etc. in case she gets lost and loses her collar.

If you’re building or managing IAM software, expand the universe to enable rich schemas in the system. Some of us may want to have a “lucky” group/policy/agent, and we certainly want better ways to identify and protect our Lola’s.

Disclaimer: The views expressed in the content are solely those of the author and do not necessarily reflect the views of the IDPro organization.

About the author

Pablo Valarezo is an Identity practitioner building and modernizing secure IAM programs over the last decade. His primary focus has been in the workforce side of IAM. He came to Information Security via system administration, project management, and audit and compliance.

The post The Identity of Everything… Else appeared first on IDPro.