EIC 2025 Q&A: Operationalizing the Identity Fabrics and Reference Architecture

Welcome to the KuppingerCole Analyst Chat. I'm your host. My name is Matthias Reinwarth. I'm an analyst and advisor with KuppingerCole Analysts, as is Dr. Phillip Messerschmidt. He is my colleague and he joins me for today's episode.

Hi, Phillip. Good to have you.

Yes, happy to be here and looking forward to this episode as we are answering a couple questions that we have received in the EIC workshop that we had. Right. EIC is over, so the work has been done, but not yet completely, because we had a rather successful and really fun workshop around the 2025 Identity Fabric plus Reference Architectures, three hours workshop together with two external colleagues, Kenny and Fabrice. And a lot of questions were raised towards us, so it was a lot of great interaction, and we could just not make it through all the questions within the given amount of time.

So we said, let's follow up on that with a podcast episode. And here we go. This is this episode. If you do not know anything about the Identity Fabric and the Reference Architecture, we would recommend either to re-watch the recording of the workshop, because this is available for all of those who have attended EIC, and also there's a possibility to license all the EIC content right now, if you don't want to do that.

There is a webinar that Martin Köppinger and Philipp did on the 15th of January, so that should be findable, or maybe we even add that to the show notes, so that you can click on that and follow up on that. So please shortly pause this video, catch up with the Identity Fabric and the Reference Architectures, and return to this to get into more detail with the questions. This is for the introduction, a bit lengthy, but now we have questions, and they go into much levels of detail, so I'm really looking forward to that and to discussing that.

They were so good that we really wanted to follow up on that. The first question that we have, when you look at the, or if we consider the overall picture of the reference architecture, there is an area that is called integrations, and these integrations integrate with a lot of other enterprise IT systems and data sources and infrastructures. The question says, you could argue that the integrations mentioned in the framework are context data sources that would need to be managed. Could you explain the difference?

That, to finalize that, refers to an admin capability that we added with this new version, which is management of context data sources, so managing all the signals and the trustworthiness of signals regarding dynamic authentication, dynamic authorization. So the question is, what is the difference between the integration and the management? And this is the question to Philipp.

Actually, we have, as you said, the integrations part, which is a row, and we have context data source management, which is a capability. For me, the difference is easily explained because integrations highlights other tools that we use data from or that we send data to, and of course, these are context data sources, but these are context data sources that we are not responsible for or that we don't own. So the data that is coming from there is not in our responsibility.

For context data source management as a capability, we need to make sure that these context data that we receive from the sources are on a good level of quality so that we can use it for automation. That is the idea. Sometimes it is even possible that we own the context data. So when we have an IGA system and we have an IDP, we are also owning lots of IAM data that we can use for context data analysis or that we can use to calculate dynamic authorization or authentication with these context data.

But that doesn't mean that we own all the context data, and neither it means that we collect all the context data. We consume it, maybe. And this is the difference. Integration means that there are other tools out there that deliver us context data, and context data source management makes sure that we handle them in the right way. It's about assuring the trustworthiness of that data and how far we can trust it. As you said, for example, automation purposes, is this data good enough to say we won't allow login from a specific network segment or something like that?

That would be something that we really need to assess, and that's part of the context data source management, while the data might come from your CIEM system. So that would be the SIEM system.

Of course, the SIEM system or the XDR, which provides that data, but it's not ours, as Philip mentioned. I think that's quite a difference.

There's, of course, an overlap. These capabilities have kind of a Venn diagram overlap, but the admin part is clearly context data source management, and the integration delivers the data. I hope that made it clear. The second question is very interesting, but I think it's also based, or the answer is based within our philosophy towards the overall reference architecture. You referenced the authentication context part to IGA tools.

Why not to reference specific tools like conditional access, with conditional access being the access management part, authentication authorization, and authentication context part is IGA tools? Where do you see the difference, Philip? The first question, or the first half of the question, is interesting, because I think we don't reference authentication to IGA. I think that's the first thing that I'm trying to handle here. The second is much easier to answer. Why not to reference specific tools like conditional access? We are not really referencing any tools.

We are referencing tool types like IGA, like an IDP, and other tool types, PUM, and so on, but they come much later in the process. When we talk about the identity fabric, we are always starting with the capabilities, and that forms services. You can find these services in different tool types. These tool types form a market, and in this market, you can find specific tools from specific vendors. This is how you translate what we do from a functional perspective into a technical implementation, ultimately, with a specific vendor. Why don't we mention them?

Simply because we are not advertising any vendors here. We are a neutral analyst company, and we look towards the functional capabilities and not how to implement them, as we are not a system integrator. Conditional access is clearly related to a specific vendor. We all know whom we are talking about. Conditional access is one implementation of this, and it, of course, falls into the categories of the capabilities that you mentioned and that we use, but it is only one option to choose. I think that hopefully makes it clear. Next one. I would love to pick that up.

It is about the term entitlements that we are using when it comes to entitlement management. The question is, entitlements are permissions.

However, this inconsistent terminology can be confusing. Can we clarify that, or can we clarify this?

Yes, we can. If you have three experts in the room, you typically have four definitions for a term. The question is, how do you define entitlements? How do you define permissions, access rights? Entitlements is one example. In the context of the identity fabric and the reference architecture, we use entitlements as an umbrella term for all possibilities how to define permissions. That includes roles, groups, but also policies, and all this is encapsulated in the term entitlement management.

That is the way that we have decided to use that term, and we use it consistently across everything that we do. Entitlement management is policy management, is role design, and a role concept. It is the group management within AD. All of this belongs together. It is ABAC, it is PBAC, it is RBAC, whatever. Having that in mind, it no longer is inconsistent, but it is consistent in our terminology that we use as Copenhagen Coal.

However, we understand that others are doing it differently. For using the identity fabric and the reference architecture in an organization context, especially when you have your own definitions of terms, it might help to get to a mapping, to a glossary, to make sure that everybody means the same when you're using a term.

For us, entitlements are an umbrella for all types of potential access rights, permissions, entitlements, whatever, all in one basket. That's the idea behind it, how we use it, and then, hopefully, it's no longer inconsistent. Do you agree, Philipp? Absolutely. If I recall my past projects, also before my time at Copenhagen Coal, we always had the difficulty and the confusion that you mentioned here, the inconsistent terminology.

For every organization, in every industry, for every customer that I had, it took me quite some time to get that terminology straight and to define everything so that we are talking the same language, basically. You could argue that entitlements, permissions, transactions, and whatever other term you can come up with is basically the same. Even AD groups are somehow permissions or entitlements.

In SAP, you have the transactions. In the end, my approach was always to talk about different access levels, if you want so, to say that if you have entitlements within an application, I call them permissions. When I have entitlements as the basic level in an IGA, I call them entitlements.

This is, again, just one thing that I define for myself. Within Copenhagen Coal, as Matthias explained, we are using entitlements as an umbrella term, which is completely fine. I think the main message here is wherever you are, make sure that you talk the same language with whomever you are talking and that you make sure that you have the same understanding of what you are talking about, because a lot of confusion comes from exactly that point, that you have a different understanding.

One of the basic terms that always leads to, unless it's properly defined in advance, one term that leads to issues is the term access, because it's in the overall identity and access management, but we don't use it anymore afterwards because we use authentication and authorization, which are the two components of access, in my opinion. But this needs to be clarified so that experts speak the same language. I hope that clarifies this. You can disagree on our use of entitlements, but it's a choice that we took. This is how we use it. Very good question.

I thought this is an easy answer, but it's not an easy answer. I think, where would you see the topic reconciliation in your framework? I think reconciliation is the sister of provisioning, right? More or less, yeah. I would agree with that. We have provisioning as a capability in the framework, and I would say provisioning is one direction. Reconciliation is basically the other direction, if we define it as the opposite of provisioning.

If we add a little bit more context to it or a little bit more functional depth to it, you could also argue that the comparison of the results is also part of this. Then it would also fit a little bit into access governance so that you make sure that both systems, the source system and the target system, whatever you are trying to provision, have the same content or have the same data. That would mean that you need to compare it and make sure that this control is positive in the end. That would be access governance, probably.

Right, exactly. The question is also maybe a timing perspective. If a provisioning goes wrong immediately and you verify, has it taken place?

No, because somebody pulled out a cable and it did not work. Then you would say, okay, I immediately do the reconciliation and then it's part of the provisioning. If I mainly do fire and forget provisioning and do the reconciliation once a week or so, which you shouldn't, then it's maybe closer to the access governance part and really controlling what you're doing there.

So, two possibilities, which is still totally fine. The question is at which point of time are you doing that?

Again, there's no black and white. There will always be overlaps, gray areas, where you can say it could be here, could be here, as long as you specify the capability for yourself adequately. We had quite a number of questions in that workshop, but also before, around the abstraction level of what this reference architecture is about. It is on a high level and if we end up with the first draft of an architecture for a specific landscape, there's not a single cable that wires one component to the other.

So, the question was, how do you map the outcomes of this Copenhagen Cold Framework, the reference architecture, to a more technical mapping? How to present that to high management when it comes to saying, okay, this means I need this and that component and this is wired up to the other systems like this cable. The question that we have here right now was issued in the first part of the workshop and you did some kind of explanation how to operationalize these frameworks and that was part of the answer that maybe was not around during the time of the question.

But maybe you want to also, or we want to explain a bit more, how do we use that afterwards now that we know how the architecture at our level, building block capability level, looks like. How to map that to something that can be implemented and put on the timeline and underpinned with tools and technology. A little bit earlier, I already explained how we have the capabilities. They are designed as services and mapped onto specific tool types.

And when we get to the tool types, we get closer to the implementation because within this market of tools, there is a vendor and this vendor has a specific tool. When we implement that, we can deliver the capabilities.

So, this is the idea. And exactly that is how you can use the framework.

So, deriving a more technical mapping is exactly taking the next step. In the workshop, we have had three parts on operationalizing.

Of course, you can also take the next step to operationalize it into a technical architecture, saying I have identified my capabilities. So, in the workshop, we had the IGA capabilities. And if you take an IGA tool, what would that mean from an implementation perspective?

So, what components do I have? How do I link them? How is the data flow? How is the process flow? How are the user journeys and so on?

So, that would automatically result in a technical mapping based on our framework. That gets much more complex if we add different types of tools, of course, and not just a little bit more complex, but a lot.

So, you should start with one tool and not add too many tools at a time. Make sure that you do it stepwise to reduce complexity or at least not increase it extremely. The second half of the question, how to present outcomes to high management. If you have a reference architecture, there's very much detail in there, depending on how you try to present that.

So, every time you have a lot of details, functional or technical doesn't matter, it's not as easy to understand for high management as for an operational expert. So, when you try to present outcomes to the upper management, to high management, to high management, you want to keep it on a strategic level. This is exactly where the identity fabric comes in and gives you the opportunity to explain that pretty much from the beginning.

So, what kind of identity type are we looking at? Which target systems are we talking about? What capabilities or what services are we trying to put in place to make sure that this identity type can access this target system? This is how you get your upper management into the game. This is how you explain that and get their recognition, their support, their understanding, their awareness. It really depends on what you're trying to do.

Even if you're trying to get sponsorship, make sure that they understand what you're trying to do and make sure that they can identify with what you are trying to tell them and what their motivations and drivers are. I fully agree. I think that really is also the language that is easily communicated and that really allows you to communicate efficiently and briefly and concise and compact. I think that really helps. Maybe this is exactly the opposite of what the question implies to say, okay, we need to present a technological architecture to the upper management.

I would disagree mostly, so I would not do that. Nevertheless, it's possible. To drill that level down, it is not an immediate part of the reference architecture, but it would be, of course, a result as an outcome of the process. One important question that came up regarding ITSM is something that we also see in many of our workshops that we execute with our customers, for example. It's the role of ITSM.

If we think back of where it's located, first of all, many organizations use ITSM, IT Service Management, for their administrative processes, for workflows, for implementation of ticketing, etc. That's the reason why we have this in our reference architecture as an integration. ITSM can serve an important role when it comes to providing workflows instead of using IGA built-in workflows. Now the question, do you see it as an interface to request access through an IGA API, so outside in from ITSM into IGA, or as part of identity management where you do the IGA and authorization logic?

That's a bit the other way around. That is a question that we see in many areas, depending on how mature and how complete the use of ITSM is. What is your position towards that? Is there a simple answer? Can we say this or that, or is the answer yes for both? We can say everything, but it's rather a philosophical, political question even. When we think about the interface, if we think ITSM as an interface to request access, that's a different thing as if we would design IAM capabilities into an ITSM. What does that mean?

When we have an ITSM integration that is just a plugin, an API for requesting access, that means that we have really just the user interface. The whole IAM logic behind that is in the systems behind that, in the IAM system, so it stays there. When we add more of this IAM logic to the ITSM tool and make the ITSM part of our identity management, we transfer logic from the IAM into an ITSM.

Usually, that's not the task of an ITSM, so that means we are customizing ITSM in a way that it can do IGA or authorization logic, and that's usually a complex thing. What is the idea behind that? What is the motivation?

Usually, the motivation behind that is to create a user interface that is looking pretty much the same from everything else, so that you have this one-stop shop, as you call it, where you can find everything in your ITSM, whether it is hardware, software, access rights, or whatever you're trying to order. That will mean, if we have an ITSM where we have just the request access functionality, it would give us a deep link into the IGA tool, and the logic stays within the IGA.

If we transfer the logic from the IGA into the ITSM, we would still have the interface of the ITSM with the IAM logic, but this would also require that we transfer all the deep IAM logic into the ITSM, like SOD, criticality, the approvers, all the audit trail needs to be synced, and this is much more complex from an integration standpoint. Concluding on that, it really depends on what you are trying to do.

If you are looking for a user interface that is pretty much the same for everything, and user experience is what you're trying to reach, you could go for the deep integration and transfer the logic, but if it is about just giving the people a one-stop shop, and then via deep link, they can jump into your IGA, I would rather recommend to leave the whole logic in your IGA because this is where it belongs, and also the IGA systems meanwhile have quite good workflow engines, so the ITSM is really just adding the one-stop shop and not that much of a user interface improvement anymore, I would say.

In reality, we see both.

If we are asked, we typically are hesitant to rebuild IGA functionality in ITSM and prefer some kind of I-frame where a mechanism that looks like the ServiceNow or the ITSM that you're using, that looks a bit like that, but it's actually the IGA solution, just to make sure that you don't have to do everything twice, which you would have to do but having a proper API solution in place might ease the pain a bit, but there still remains the pain, but this is a hot topic for many organizations who have a strong ITSM strategy, who need to have a strong IGA strategy, and now you have two cables that you need to wire up, that's an issue for many organizations, and no simple answer.

Coming to no simple answer, how can IAM and specifically IGA help in the shielding of identities and what are the possibilities? HR should not be the only source, which is true, and the more important identities become, the more this becomes an important question because 10 years ago, life was simple, HR was providing good data, it was fed into the identity management system and from there on into the applications and that is it.

Today, we are facing different challenges and the question is, how can we be better in shielding identities and what is possible? Do you want to start or should I start? This is also philosophical and it's technology and that is really important, so I give you a first shot. Let me try to structure it a little bit. When I think about that question, it comes to my mind that basically when I think about X, I have three major dimensions that I need to think about.

I have the identity on the one hand, I have the object that I'm trying to access on the other hand, and then I have the how in the middle, so how do I access this target system or application or whatever I'm trying to target. With that question, we basically tackle only one of the three dimensions, the identity, and within that dimension identity, the HR system is mentioned, but when we think about that and the three dimensions as a whole, it's really about attributes. What happens here?

HR is trying to give more attributes and more verification to the identity, but we should not forget about the other two dimensions, so we should think about the object and try to get more information about the object. The better we know the object, the easier it is to explain how the access happens and under which circumstances. As you said, it's a little bit philosophical and this is more or less where Zero Trust comes into play. We are trying to get more context information from all the different perspectives and try to match this information.

That means the better I know the object, and I can say the object should just be reachable from Germany, for example, I can make sure that it is just reachable from Germany, but that would require that I know where my identity comes from. If my identity is from Germany, it can use that target system, but actually it's not that easy because when my German identity moves to France, can the German identity still access the target system? That depends how I define how that object exists because the German identity is now in France, so that will mean we have a different network.

When I describe how it is accessed and there's all of a sudden France in the game, the target system should not be reachable even if the identity is from Germany. The conclusion here or the summary of what I'm trying to say is, obviously, IGA is helping in more than just one way. It's more than just the identity that we are trying to secure. We are adding context info over all three dimensions and with the rules that we have, whether it is identity to object or identity to the access or access to the object, all of that adds another level of security here.

Yeah, absolutely. The question focuses very much on IGA.

I think we can go also beyond IGA because everything that you described, so enriching an identity with additional attributes that might be maintained during the admin time, that might be added during the usage of the identity for authentication, for authorization purposes to understand what this identity actually is expected to do and what it should do and what it actually does and to derive some kind of normal expected behavior and then identify if this identity, and we're talking about shielding, protecting, securing identities, and if this behaves differently, maybe something is wrong, maybe it has been hijacked, maybe it has been taken over, maybe the actual owner of the identity goes rogue and does things that we do not expect him or her to do.

That is something that is traditionally, if you can talk about tradition for a term that is two or three years old, it's allocated in the ITDR area, so identity threat detection and response, it's all in that term. To identify threats, to detect them, and to respond to them, that is part of IAM, of the overall bigger picture of IAM. That is a capability that stretches across all areas that we have in the columns, so it's from admin until authorization.

Of course, these technologies can help in shielding identities, and that was the question, so understanding this technology as an enhancement of securing identities, that is really an important part, and we're talking a lot about identity security or identity-centric security. Here we go. This is exactly it.

Understanding the identity, providing every piece of information that is reasonable, makes sense, and is well-assured, and then act upon that in authorization, provisioning, but also authorization at runtime, so there's a lot more to do, and that answer could fill two episodes of a podcast, how you can really ensure that the overall picture of the identity fabric and the reference architecture can support in protecting identities. We could do much more. We typically don't. There's the saying we only use 20% of our IGA system, and now we add additional functionalities.

There's much more to do, and we should, and the reference architecture is one way to identify the next steps. As you can see, the questions are colorful, and they are looking at various really interesting aspects. The next one, I think this is a real Philip question. How do you deal with multi-role-based employees, so one person having more than one job in the organization, maybe being an admin, being a regular employee, maybe having additional capabilities, and that means how do you deal with that?

The question here says this means multi-registration in the HR system, so identity information needs to be checked on multi-usage. Could be, but this is only one option, right? This is a rather complex question, to be honest. Sometimes with some organizations, we are discussing that they don't even have identities yet, so they are doing everything on account basis. We already had the question about the terminology. Accounts are target system-specific or application-specific, and the umbrella term is usually that we have an identity.

With the identity, we summarize all the accounts to one person. What happens now if we add more identities next to it, so we have more of these umbrellas?

Usually, the identity is created in HR, so this is the usual approach. What happened in the past years or what we are trying to advocate at the moment is there are more identities coming up, also more personal identities with different job roles, different context. That requires these identity umbrellas to become the next level umbrella. This is where we add a unique identifier to the identity and move the identity one layer up, but that leaves us with an empty level in between. This is again a thing of terminology, so we would call that a persona.

That means that one physical identity has one digital identity with the digital unique identifier. That is the big umbrella, and below that, you have different personas. One persona is the normal user. One persona could be the admin. One persona could be a project expert somewhere abroad. I don't know. Every one of these personas has different accounts and different target systems. This is exactly the context. What is here mentioned as multi-role or multi-usage and needs to be treated differently because that means a different context.

The problem with that is how you manage that effectively in your systems. I think that is a question that goes beyond this podcast, but this is really a challenge. Let me summarize it like that. Right. That has deep impact also on your lifecycle management processes, how you really deal with that. Another example could be external workforce with a load of contracts that change over time and maybe contracts existing at the same time in parallel leading to different access rights. This is a situation that we often see, and that is nothing that can be solved on a I'm the bright analyst.

I have the simple answer. There is no simple answer that needs to be modeled according to your lifecycle processes in the source systems and how they need to be reflected in target systems. That is applications. That is the auditing. That is the contract management. In the end, it is doable. It's something that needs to be well-defined. A good process workshop or two might help and how to reflect that then in the overall IGA system. Sometimes the only answer is there is no simple answer.

I have mentioned that before, colorful questions, completely different angle, actually not really related to the reference architecture, but nevertheless, an important question, which business role, which driver would typically lead a company in its IAM journey? Who's the person to do that? We take one step back. Who would be the person that we talk to when executing the workshop to define this IAM strategy? We've seen many possibilities, right? Absolutely. That highly depends on how IAM is positioned within organizations. Sometimes we see IAM teams sitting in the infrastructure.

Sometimes they are part of the security organization. We have lots of other places where IAM teams sit. Ultimately, if we go up the branch in an organization, it usually comes down to different C-levels.

CIO, CISO could also be a possibility. Ultimately, it comes down to what the motivation behind that is. Is it efficiency? Is it security? Are the regulations? This highly depends what this business role, as this is here asked in the question, what the driver is that this person drives. When it is a security person, it obviously is on the CISO side or regulations also often on the CISO side. If it's efficiency, it could be a revenue officer or it could be something else. We have seen teams in the infrastructure, so it was driven by efficiency a lot, but not in a way that it should create value.

It should just work as an infrastructure, obviously. Less tickets is more value, which is definitely not the best approach to IAM. Answering the question, it really depends on what you are trying to do and what the main driver of that business role is in the end. No matter who it is, I think it is important that there is a designated person that actually does that over a longer period of time to be able to formulate a strategy and to pursue it. I think that is important.

Then everything that you said, Philipp, is completely true, but there should be somebody who actually does that because an IGA and IAM that is not well steered like a ship will not deliver over time. That, I think, only will deliver partial solutions. Two questions left, both very different questions. I read out the first, how to manage internal identities that are directly handled in external SaaS apps. Think of GitHub, anything that is provided as software as a service, and how to make the link with identity repositories or IGA identity lifecycle management.

You have something that is somewhere else that is managed there or should be managed there or is obviously managed there. How to link that and how to embed that in lifecycle management. Starting point from you, Philipp? There were two directions I was thinking about. The first one is, well, there are standards out there, technical standards, so you might want to use them. Thinking about SCIM, for example, you could easily connect that. There are tokens that you can use, even though that's not the best way in my personal opinion, but this is how you could technically connect that.

The second angle from where I was thinking about this is, why do you have these SaaS applications that are obviously locally managed? At some point in your policies, in your guidelines, you made a mistake that you don't forbid that. IAM should be part of every application onboarding. Every new application should face the requirements also of IAM. Your requirements for a new application should be that it can connect to your IGA and make sure that the lifecycle is managed centrally or that this application meets the minimum requirements that you have from an IAM perspective.

Make sure that not everyone is buying SaaS applications with their own credit card and are using stuff from the internet. That is not just an issue from an IAM perspective, but a real security threat to your organization. In the end, it's kind of shadow IT. It's a bad word, but it needs to be mentioned here. There are technologies around that really prevent that. Embedding that into the process framework, what you've mentioned, the lifecycle management, making it requestable, even if it's then manually provisioned. Don't tell anybody that I said that, but it's integrated in the process.

There's a provisioning. You understand the actual status of that account, and it will be subject also to mover processes so that you disable or at least pause that account when somebody is on a sabbatical for six months. I don't know that you don't have to pay it anymore and that it's not active anymore. This is something that is part of lifecycle management provisioning, the usual IGA game. One thought that we could add here as well is something that still requires good processes, but might help technologically.

That is just-in-time provisioning so that you just create the accounts at the moment that the application is used for the first time and that you have safeguards around that make sure that if it's no longer used for a period of time that it gets deactivated, removed, deleted, whatever. This is just a technical solution that might help in not doing the provisioning the hard way via SCIM or any kind of adapter, but the account is just created on the fly when you need it, which requires some additional thoughts, but it's possible and doable.

I think that's an additional thought so that you can do that. Everything else, if you think using a popular SaaS platform integrated into your processes, and I'm also talking about Salesforce, Teams, whatever, make sure that these are well-governed and integrated into your lifecycle management processes. If you invite externals, take care of the externals. That's a completely different game.

It's B2B, B2C that you need to manage as well and proper lifecycle processes, different identities. Anything to add to that or we move to the last question? That is a very short one with a very long answer. We mentioned CTNA as an integration service, and that is, I think, completely right. The question is why not CTAA?

First, explaining the acronyms, CTNA is Zero Trust Network Access. CTAA is Zero Trust Application Access, and these are different beasts. I start with CTNA and you continue with CTAA, and then we explain the difference. Very briefly, CTNA is a network infrastructure that is provided as a service. You get some kind of virtual networks with all the security mechanisms that you consider relevant for a network that you get somewhere else. It's a replacement for the good old VPN, and you replace it with a fully structured segmented network infrastructure that is provided by a CTNA provider.

They give you this infrastructure, and you say, okay, I need an entry point here and there and there, and that combines my networks internationally. I have functionalities in there that include everything that I need, protection of inbound traffic, protection of outbound traffic, and all of this is CTNA. Is it a good term? I don't think so, because it's Zero Trust Network Access. It's Zero Trust because it's sexy, and it's network access because it's still provided network infrastructure, but in the end, this is the term, and that's why we use it.

It's used, and it's understood, and that is something that we need to integrate. Why? Because the CTNA requires identities, because all network access will be based on identity, on context, of course, on networks, everything that Zero Trust is about, but you need to have good identities in this as well, and that could be also machine identities, device identities, and people identities. That's why we call it an integration, and why we put it into the authentication authorization part. There it is located as an integration. That is the answer for the first part.

We think it is an integration service, and it's important when somebody has CTNA integrated properly. Now over to Philipp to CTAA. To be honest, this was a new acronym for me when I heard it the first time, but when we think about that Zero Trust Application Access, that basically means how do I access an application under Zero Trust? Zero Trust basically means never trust, always verify. In other words, whenever I access an application, I should check all context information and the identity and the access. Never trust, always verify.

This is nothing else than what the normal access controls are doing when they are not static. When we have dynamic authorization, we always check with every access. We check if the identity is right, if the context information is right, if the access is right. In other words, Zero Trust Application Access is nothing else than dynamic authorization under the umbrella of Zero Trust. That means we basically have a different form of PBAG or other dynamic authorization. Why is that not in our reference architecture?

Well, obviously it is. This is why we have not Zero Trust Application Access Control or whatever we want to like to call it. It is basically another sexy acronym where we were able to put Zero Trust. Nevertheless, the idea behind that is A, important.

B, I think it is relevant and we should do it that way because it is part of the overall support through identity and access management for Zero Trust because it is an enabler technology in the end. But I think the terminology is not necessary in our context because, again, we talked about glossaries and about terminology before. That for us is in dynamic authorization and maybe in dynamic authentication as well. The combination, the access part, and I think that is well covered there.

It is not only not an integration, it is an integral part of the core of identity and access management when it comes to dynamic authorization and authentication. The answer is both are in there. One is an integration. If you have CTNA or call it SASE or whatever you want to call it, the terms are not really well defined and overlapping there as well.

For CTAA, it is in there but not using that acronym, but we could. We are through the questions that came up in the workshop and that we thought make really sense to follow up on them. I would have no regrets to follow up on that if you have more questions. If you as the audience have made it through 50 minutes of answering questions and think we have not yet answered your question, please reach out to Philipp and or me. Send us a mail. We are easy to find via the website.

If you are watching this on YouTube, you can just leave a message in the comment section and we will follow up on that if there is enough questions. It is great for us because it challenges us. As we said before, that is a new iteration of identity fabric and reference architecture and there is more to come when we are talking about second level reference architectures and that is something that we are creating. We heavily rely on your feedback, on your questions, on your scrutiny if everything that we say makes sense or if there is contradiction or incompleteness.

Really, tell us the questions. Challenge us. We want to get to a framework that is appropriate for almost every use case scenario and that is the reason why we love these challenges. That is the reason why we picked up these questions and did the workshop at EIC. Final words, Philipp, before we close down. Anything to add from your perspective? The workshop was great, right? Right. I think this podcast episode is one of the most diverse, at least from a content perspective, that we had so far. Looking forward to more questions. As Matthias said, if there are more questions, let us know.

Contact us. Challenge us. We are looking forward to it. We keep it with that. Thank you very much, Philipp, for joining me today, for following up on the workshop, for taking the time, for going through these questions and looking forward to having you in another episode very soon. See you. Thank you. See you. Bye-bye. Bye-bye.