Welcome to another episode of the KuppingerCole Analysts Chat. I'm your host. My name is Matthias Reinwarth. My guest today is, once again, the principal analyst of KuppingerCole and one of the founders of KuppingerCole Analysts. It's Martin Kuppinger.
Hi, Martin. Good to have you.
Hi, Matthias. Pleasure being back. Great to have you. And today we want to dive into a topic which is really a, what we say, hot topic, but it also has some aspects that still are under discussion, under heavy discussion. Some terminology wars are going on. We want to talk about NHI machine identities slash workload identities. And so usually the term used is NHI, non-human identities. Before we go into discussion around the terminology itself, first of all, what is a non-human identity and what makes it different from secrets, for example, from credentials or accounts? Yeah.
And I think you're bringing up an important point, but also potentially risking a very philosophical, fundamental, foundational discussion. Non-human identity and the understanding the industry has are identities of non-humans. So we have the identity of humans, like an employee, a customer, et cetera. And we have others, elements, entities that in some way have a digital identity that are, so to speak, silicon-based.
And that would be the easiest discussion, but it brings us automatically, I think, to one of the things we'd like to touch in this talk, which is around identity versus secret, versus account, versus entitlements and all the other stuff. So I think it's currently, realistically, it's an umbrella term for stuff that is, so to speak, covering all the aspects of identity management that are not directly related to humans. Right. And I think I have to mention that I'm a bit of a language fanatic and etymologically, it's clearly wrong to define something with a term that begins with non.
So being something not is not a definition at all. But this is something we need to live with, as you said. So we are used to human identities. We are used to deal with them for years now, as Copenhagen Coal is an IAM company. So the non makes sense in that case. But if we look at the bigger landscape, this NHI, as you said, is an umbrella term. And I think the umbrella is rather large, and there are lots of very different types of identities below that, that range from very, let's call them stupid, in comparison to intelligent or autonomous.
So it's the full range between a machine, an API key, ranging to workload identities and agentic AI. So I think this broad range of non-human identities a bit justifies the term NHI.
Yes, I think we can work with this term. I think it's okay. I prefer it over machine identity because I think machine identities, on one hand, my association of a machine as something that moves and makes toys and so on. The other element is that certain parts like IOT, OT related stuff, et cetera, so to speak, is much closer to what we commonly associate with the term machine. So from that perspective, I would see machine identities more as a subset within non-human identities.
And yeah, I think it's an interesting thing because I think that's probably a rather general thing to approach sort of things within IT and probably beyond. We have two extremes we can potentially take. You could just say there's an identity, maybe this identity is associated to accounts, have entitlements, there are certain secrets assigned, et cetera. And we do it very, very generic and say, okay, it's an identity. And at the end of the day, there's quite some similarity between every type of identity.
Or we try to come up with a finite list of identity types, which I think we already experienced triggers a lot of discussions. So do we need to distinguish between a consumer IOT device and an industrial IOT device? Are there maybe even multiple groups of industrial IOT devices? What is really more an identity versus an account versus a secret? Is the identity term for the non-human identities the same as for human identities? So for human identities, we have a person that has potentially multiple digital identities in the private or in the personal life and the business life.
So there's the user which has different accounts. So it ends in a representation of that. The question is, for instance, has a non-human identity always a one-to-one account relationship or just a secret relationship or may have a one-to-an account relationship?
Again, so at the end of the day, we end up with a lot of questions and I think we need to be very careful not to end up in chaos by either being too sloppy with our definitions or ending in chaos by trying to be too perfect in defining everything.
I think the approach that you just mentioned, so having an identity no matter what it actually is and adding a set of attributes which specify these identities and that could include ownership or is it human or non-human or is it long-lived or short-lived, that is most probably a much better approach because it gives us the flexibility over time to adjust to upcoming new identities as we are just doing with these new types of non-human identities, especially agentic AI.
I think that's a good starting point because when we've learned something around identities, it's not that it's getting more rigid and more structured but that it's getting bigger and the field is getting broader and that is what we're just experiencing. It's interesting, I just yesterday had a bit of a discussion around how can we maybe just visualize these relationships, your product, the owner.
Once you start thinking about it, it becomes really interesting because when you take a workload, so as a piece of software which is part of a bigger piece of software, an application for instance or a SaaS service, and then you have instances of the workload which are ephemeral. So the workload itself is not ephemeral, the instance of the workload is ephemeral. The workload is related to an application. The owner of the application might be a different owner than the developer that is the owner of the workload.
Then you have for that workload, you have potentially one or multiple service accounts that are used and other types of things that have entitlements to certain resources somewhere. Then you start, by far not at the end, because we have secrets, etc., as well in this picture. Then you end up with a visualization, maybe an entity relationship diagram. I'm old school, I still think in these terms. I learned someone sometimes back in the 90s or so. But it still helps, I think, visualizing it. That just shows how complex it is, what we are talking about.
There are also a lot of different elements in addressing this and solving this. There's not the one NHI thing, it's a pretty big piece to tame.
Right, and as you said, if you think of entity relationship diagrams or if you just think of graph databases with labeled vertices, I think that is something that allows you to model this overall concept that you mentioned. Drilling down from entity to identity to account, maybe with some personas in between, and finally the credential. I think that is the much more important part, rather than getting to grip with the terms for these non-human identities. I think in distinguishing between the identity, whatever it may be, the account and the credentials, that is much more important.
Having proper definitions there is something where we can draw from experience. Yeah, I think it helps. On the other hand, I think what we also should see is that there are differences between non-human and human. But it might be also something where human identity management sort of evolves by learning from non-human identity management. There are clearly blurring lines. The typical privileged access management use cases around functional accounts, that is somewhere between human and non-human. So to speak, non-human, human accounts, we use as functional accounts, in a sense.
What I feel interesting is there are a couple of things that come in as new challenges with some non-human identity management. One is, I would call it, Walt's Brawl, which is probably the least new challenge, because we had this identity silo stuff, etc., also. So just decentralized, or getting a grip on decentralized worlds, is something where we have quite some experience in traditional identity management. On the other hand, non-human identity management comes with the challenge of scale and the response of automation.
So we only can handle scale when you automate, which is something where we could learn quite a lot for the classical world of identity management. And the other thing is also this discovery element. So understanding where are these used, where do they exist, etc. And I think when we look at discovery, and then maybe also the usage, when we go to user behavior analytics, or to avoid the old-school term, if we apply ITDR to non-human identities, then clearly there's also an interesting intersection, potentially learning in both directions.
So I think that's also a nice thing that we, on one hand, sometimes have probably some expertise in handling things that pop up right now. In the non-human identity world, on the other hand, we are also facing a potential of learnings to get better in traditional identity management. Absolutely. And I think if you look at API keys, at a workload identity, usually they have a very defined range of potential actions where you can look at. So you can most probably deal with traditional ABAG, RBAG, access assignment, credentials, entitlements, because you know what to expect from them.
The API key, you're quite sure what it does during its lifecycle, its existence. Human identities and agentic AI, they have a sense or they have a notion of agency. They can do things autonomously. They make their own decisions, both people and agentic AI. And they are not that easy to tackle with traditional access rights. He has that role, she has that role, but they will change their behavior over time. They learn and they adjust over time. And maybe they do things unexpected within the boundaries that they're allowed to.
So dealing with agency, dealing with autonomy is something that maybe even human identity management can learn from agentic AI, because there these ITDR mechanisms come into play to understand what is expected, what is normal, what is unexpected, what is rogue and not normal. I think that's a good point. Yeah. I think it probably other things in all directions that we can learn. I think there might be also across the different identity types, it might be very valuable to look at capability areas or capabilities.
So there are certain capabilities that are very sort of similar across different identity types. So vaults, for instance, are something which is rather similarly used in many areas. And there are things like discovery, which come in with certain types. There is the access control things. There are whatever ownership management is needed at the end of the day in some way, almost everywhere, probably everywhere in different variants.
And when we look at capabilities, we will potentially be more easier able, faster able to figure out what is common and which are the clusters of sort of identity types we really should look at. And at the end of the day, it might be when we go from the one extreme only, we say there's an identity that could do something truly too generic for a lot of things. If we look at a finite list, or probably never a finite list, it's an infinite list.
It's not infinite in the mathematical sense, but it's impossible for us to define the finite list of identity types in a stable manner, because there will be always new things that we have to discuss about what to split, what to merge. But if you take that list and the capabilities and build a matrix, we should be able to come up with a set of meaningful clusters of identity types, which probably are workforce and partner, partner is a bit tricky, and customer consumer, and workload, and machine sense of things, et cetera, and AI agents. That could be a good starting point.
And I don't think we will have that many other clusters, but these are probably the ones which have for itself always relatively strong overlaps of the different capabilities needed. Right. Maybe it's also a nice approach, at least think of not thinking in identity types, but in use cases, what these identities actually do. So no matter what they are, but what is the expected behavior, what are their attributes, what is their lifespan, their life cycle, maybe that's also a good starting point. So I think we finally managed to very elegantly avoid the definition of NHI.
And I think that was maybe the best achievement of that podcast episode. But if we still think of organizations having NHI, from your perspective, final question, what are the biggest challenges that organizations still have to face when they define, manage, and secure their NHIs across their environments? What would be the three things that you would recommend to organizations to start with? So the first thing is stakeholder management. We're talking about security identity developers, architects, bring them together, figure out a way that everyone can do job well.
So I think it only will work in a cooperative. Stakeholders may vary a bit depending on the type of NHI, but at the end of the day, stakeholder management is essential. Then I think, basically, I would say that you can work from there in a much more structured manner. And what you should avoid is having, at the end, many human identity NHI silos. So put all this into a framework such as the Identity Fabric. Only two recommendations, but I think they should be sufficient. Maybe I add one discovery. I think many, many identities are created without proper processes, and this is increasingly so.
Whether you call it shadow IAM, shadow identities, or whatever, this is something that's coming up, and you can only control what you know of. So having a proper mechanism in place to identify, to discover those who are not managed, who are bypassing traditional processes, I think that is also an additional starting point. And then it fits into everything that you said before. So especially stakeholder management, find those stakeholders who create those shadow identities and make them work better. Right.
So thank you, Martin, for being my guest today, for shedding some light on the ongoing discussion. There's lots of discussion going on on LinkedIn and other social media, and there are strong opinions, but I think the most important thing is that we make things work. We live with the term zero trust and its weaknesses for years now, so maybe we can live with the term NHI as well, as long as we know what both mean to us. Really looking forward to having you again, Martin, in one next episode, and maybe we then can cover some of the questions that arose from this episode.
So if you're watching this episode, if you're listening to this episode, please, and you have questions, of course you will, please drop me a message, drop me a mail, or leave just your comment on YouTube just below this video, and we'll follow up on that. And I will invite Martin again to have a more thorough discussion on that topic again.
Thanks, Martin. Maybe someone does the heavy lifting of coming up with the graph or entity relationship diagram or the metrics of capabilities to identity types as a foundation for further discussion. That would be great. That would be great, then the analysts don't have to do it. That's good. Okay. Thank you very much, Martin. See you in the next episode. Thank you. Bye.
