Thanks, Mike, for the nice introduction and welcome to our today's discussion. We don't want to say we have a presentation today because the topic is digital sovereignty. And in our opinion, especially with the development within the last past years, we think it might be becoming such a thing like buzzwords and a marketing term at this point. And ask yourself, when was the last time you have heard the word digital sovereignty? Probably yesterday or maybe today already, at least within the last weeks, because a lot of people at this point claiming to work and be digital sovereign.
When you listen to the people, everyone's cloud can be trusted, everyone's platforms or softwares are compliant and fully independent. And so if everyone is sovereign or is working sovereign, what value does it leave to the real term?
And today, me, Nils, with my colleague Elmar, we want to discover what's beyond the buzzword. We work at BareID. We are an IAM vendor and also here for the first time at the EIC. And feel free to join us, by the way. We are on the C floor. But our main goal today is to show you some real life examples, logos, certificates, seals. What you can actually see in the market and how you can validate for yourself how independent and sovereign some vendors and service providers are.
But before we dive into real life examples, let's look at the numbers we are currently having today in Europe, because it's the hot topic here and everyone wants to work and be digital sovereign. But the numbers in the market actually tell a little different. When we're looking at the digital infrastructure, we see that more than 80 percent is already covered by three big vendors from the US.
It's AWS, Microsoft and Google. And by the way, it's not about attacking those companies or saying their product or services are bad in any way. We are more behind the question, how much dependency is there actually? And if we go a little step down, the cloud market itself is over 70 percent owned by those three players. And what's a little shocking, in my opinion, is that Microsoft is already with more than 77 percent implemented within governmental and public sector structures. So is it just a debate we're having and let the others deploy it?
Because the real question is, how much dependency is there and what do we actually need to validate ourselves? What's all behind the logos and the services we are actually using? Let's start with the first one. And in this case, I'm guilty myself. I use a Google account privately as well. But you might discover this one once you try to log into your Google workspace and you encounter a lot of buzzwords. Your data belongs to you. Sounds very nice, right? But what does it actually mean? Gemini protects it with enterprise privacy and security. So that sounds very nice.
It's a lot of great marketing. But the question should be what's actually behind it. Is there a legal framework, for example, behind Google? And obviously there is, right? You all know probably about the U.S. Cloud Act and Google is obviously a U.S. player. In this case, the U.S. Cloud Act in short terms means once a U.S. court requests access to data for whatever kind of legal case, it can be granted. And therefore, it doesn't matter where the data center is located. It can be in Dublin. It can be in Frankfurt, in Berlin.
In this building, if it's owned by Google and there is a legal case, they will get access. And therefore, there is also the topic with the vendor login in this case. If you put all your data into one provider, you might be risking that you're going to have a hard time once you decide to get away with it. And I want to repeat it again. It's not about attacking. It's about how much dependency do you want to have in your stack? Another example, another logo you might have encountered as well. Trusted Cloud and especially with a nice German national eagle and a ministry behind it.
It sounds very trustworthy, right? But let me tell you one thing. The question should be asked, like, what's behind this certificate? What was the scope and how did the provider or the vendor get to this kind of certificate? And the serious thing about certificates is numbers. Every trustworthy or serious certificate should have some kind of a service number which should provide you something to investigate on. And in this case, if we follow the 10021, we will be led to Alibaba Cloud. And also in this case, not validating something Alibaba Cloud offers in terms of services and products.
Just want to say we've just been to the US. Now we are led to a Chinese cloud provider. And same case scenario. It's not the US Cloud Act right here. It's the Chinese intelligence law which comes in place and it basically tells the same. I think I don't need to repeat it right now, but also there is governmental interest in some cases. The Chinese government can access this specific cloud, which is the Alibaba Cloud. And what's way more important about such a certificate? What was actually validated or audited when it comes to the Alibaba Cloud?
And if you even dive deeper on this one, in this case, it was only the trust center. So the whole scope is important to this matter, right? So therefore, always be very careful and check the numbers. Dive deeper on specific certification and see for yourself what is actually in your own hands and what might be controlled by other players right here. And before someone is saying the German guy from the German vendor is only attacking international companies.
No, we have the same for German certificates as well. This is something from the Federal Association for SMEs in Germany. It's called Bit.me. We are a member as well. And this is also not meant as negative PR. They're doing great stuff and great work and they're bringing a lot of great companies together. But they offer a certificate or a seal that says the software is made in Germany. And also with the 100%, it can be a little confusing, but also should be, of course, a certificate which says this software can fully be trusted. But is it so?
Obviously, we have investigated on this one as well. And if you look at the guideline, it says the essential steps of the production had to be done in Germany. Someone knows what the essential production steps are? Probably nobody. But we figured out it was the conception and the quality assurance. If that is done in Germany, you will get to this kind of certificate. And we all know software supply chain has a little more important scopes behind it. It doesn't matter. For example, the APIs, the service, the hosting, the codes.
And it was actually Emma's idea to reinvent the structure and make it a little more transparent. And we came up with that suggestion and conclusion. The software is now not made 100% in Germany, but it's designed in Germany. The code can be written worldwide and the infrastructure can stay run on US clouds.
As I said, not meant to be in an attacking or negative way. Just want to get some transparency into it and advocate for own self-validation when it comes to those kind of certificates. And the last one, and we, by the way, claim it ourselves this way, GDPR compliant. One of my favorites, because it basically is a self-celebration for following basic law. And everyone has it on their website. And therefore, yeah, your data is safe. And I hope everyone is following the GDPR because you should do it in Europe. But the point here is being GDPR compliant doesn't mean you're sovereign.
We have talked about different kind of laws and international legal guidelines, which can be applied here as well. So, yeah, please be very careful when it comes to different kind of certificates. And what's very important for every important IT presentation and talk is, of course, an iceberg model. And therefore, we have made one ourself for our talk and basically put all the stuff we have just presented right now on top of the iceberg. It's what you can actually see and what it's portrayed and marketed to you when you, for example, visit websites, talk to people and everything.
Server location matters, of course, but as we all know, depends on the law, which is behind it. But also the certificates you will see. Check for yourself, investigate, take the time. It's very important, especially when you claim to be or aim to be digital sovereign in this case. But what's left, we figured it out as well, is who is actually the control of your data? Who can get access in an emergency case or in whatever legal interest, for example? Is it actually auditable? Like who is behind it? Who certified it? And what's the interest of the certifier?
And of course, is there something like a vendor login? Because we see a lot of migration projects which have a hard time getting the data back into another system. So be very careful where you put your data to. And now to connect the dots, we want, of course, we are at the IEIC. We want to talk about identity and everything. And therefore I hand over to Elmar. Thank you very much. Let him have a talk about how identity access matters. Right.
Thank you, Nils. I think you just figured out to look into certificates, to look behind it and to how important digital sovereignty really is. Now let's deep dive into that topic. And why are we at the IEIC? Because digital sovereignty, of course, is important for everything. But especially when it comes to identities. Because identities are controlled within IEM, of course, obviously. But what is underneath? You do have users. But additionally, what we also do see is that, of course, workloads are controlled in the same way. Services. We talk about AI, agents, all of that. And APIs.
So all of that is connected. And that leads to the platforms. So whenever you talk about SaaS, it should be your ERP system, it could be whatever. Then it is also controlled by the identity access management system. All your cloud providers, all partner APIs. Everything is controlled with your identity access management. And that means underneath all your data, all your workloads, everything is there. So that means the identity access management system is the central control plane of your organization.
And that means you have to have a couple of questions that you should question yourself and answer it best way. So what about vendor switching? How easy is it for you to switch the vendor if you don't like it? With your identity models, with the roles and policies, with everything underneath. When we talk about European cloud workloads, nice, there is the European tick mark. But as Neil mentioned, what about the identities in the US platform? How independent are you then? And of course, if your critical business processes are running there, what about the availability?
And what about the external identity access management services? How trustworthy are they for you? And do you really want to trust them? And in the end, it is not only a security tool like in the years before perhaps seen. It's more than this for your digital organization. That's the important thing that you should take away from this speech. So when we talk about digital sovereignty, it also often connects to digital autonomy. What does that mean?
Well, we have two different views. One is the digital sovereignty. It's more a political regulatory view. And then we also have the digital autonomy. And digital autonomy means in this way a technical and operational view. And both is needed because you have the three here in grey topics. It's the operational capabilities. That means how easy is it for your organization to really be technically independent, to really operate even the critical business processes whenever, whatever the vendor of your identity access management system does. The second is adaptability. The world is changing.
We have geopolitical influences that come along. How easy is it for you to react there? How independent are you there?
And then, of course, APIs, all these changing systems with AI agents and all of that. How easy is it for you to include them and to work with them? And then dependencies. Do you really have the control over all these dependencies? Or are the dependencies controlling you? That's the question behind it.
And then, additionally, it's more complex because it's not a one-time state. It's not something that you can buy. It's something that you have continuously to prove. You have to be in a process of control all the time and getting away. In this case, all this what you feel as cloud comfort, and I like SaaS. Everyone likes SaaS, of course. All of that is something that also gives you a feeling of freedom because the cloud provider is taking care of all these nitty-gritty details and all the things.
But, in fact, you're losing control because you are not running the system. You're not in control of the system. And you get a dependency on the platforms. That means, in simple words, a vendor login. The problem with that is that we have a digital sovereignty and digital autonomy, and it does not mean autarky. I don't say let's get back to the good old times in the 1980s or whenever when the world was more simple. It does not mean don't take any cloud service, don't take SaaS or stuff like that. That would be absolutely wrong. Even not taking U.S. companies. There are good reasons to take U.S.
companies. There are good reasons to take Chinese companies. All of that does make sense. But you have to balance the risks, and that's all we are saying. That is the takeaway from this talk. Balance your risks and be sure that you think about the risks and the conclusions for your personal business, for your company that you're working in. Look at the dependencies. Maintain the abilities to exit and switch, and be in control of the system. Be honest to yourself.
Don't just take the tick marks and think about, yes, we are digital sovereign because we have made all tick marks when a vendor is selected. Really think about what is behind. And not only thinking about problems, because Germans like to do that.
Also, next step, what are the simple solutions? One solution could be, first of all, think about open source. Not as the only solution. Not as a paradigm for everything. But if a solution is open source based, then you have the chance to even look into the source code. You can see if there is a trust behind it. And be sure by proof. Use solutions that are open by design. Look at open standards. We see a lot of vendors running around here who have implemented kind of industry standards, but are kind of the standard, because they want to trick you into a dependency. Look at this. Don't do this.
Try to stay on the open standards, because it gives you interoperability, and it gives you the chance to really switch to another vendor if you like to do so. And think about vendor lock. It makes sense in some cases to get into a vendor lock, but in other senses it does not make any sense, because sometimes it makes sense to separate your critical IT systems from vendors that you don't trust and build an independence plane of that. And then if you want to have a German supply chain, well, go for it. There are enough solutions.
In some cases, when we talk about defense, military, whatever, public sector, there are laws where you have to do this. Not always followed by the companies and organizations, but however they are there.
So, there are solutions. Look around. Don't be shy. There are solutions around. German solutions and European solutions are better than many people think.
And again, it's not an ideology. I very often see discussions around get away with US companies, get away with Chinese companies. That does not work.
That's, from my personal point of view, absolutely bullshit, because there is not the right and the wrong. There is always a risk management behind, though it's a topic for risk management. It's a topic for regulatory accountability. It's a topic for business continuity. You read to run your business, and you need to make sure that your business is running.
And again, it's a competitive advantage. I always don't understand why everyone thinks security is hindering you to do business or things like that. It's exactly the opposite. A strong GDPR is a strong sign for companies who follow them, who are in Europe, and it's not hindering the business. It's a competitive advantage to say, we are following there. We give you the freedom of digital sovereignty and autonomy. We have not invented all of these ideas, by the way, unfortunately. So this is something that you have seen since years. We talk about zero trust and network security models all around.
In the years before, we are talking about identity as the central center and all of that. And now we are also talking about identity fabric. And that is exactly what we are saying. It's a mesh of different solutions that need to work together. You have not just Lego bricks, and I'm quoting Cooking or Coal. You might have heard about them. And it's about production, being there, being in the same. It is all about, it's not a label. It's a capability to be digital sovereign.
And that means digital sovereignty begins with your identities and autonomy begins with the identity access management system. That's the main takeaway. And we are happy to connect to you. If you like the slides, you also can get them. Just ping me with the app here or over LinkedIn. We are here and happy to answer your questions also at C at the booth. Thank you very much. We perhaps have time for one question. Does anybody have a specific question?
Okay, so I will ask a question. What do you think of the standards that have been introduced like the European Cloud Sovereignty Framework and the German C3A standard to do with sovereignty perhaps? It absolutely makes sense, but it should be followed. And that's exactly the problem that we see in the field. A lot of standards are there and good ideas are there, but no one is prosecuting you if you don't do it. So you just have, you can do it, but it's more like a guideline and that has something to be changed.
And we need certificates who are worth the name certificate where you really can follow the guidelines and that is really behind. Lock them up. Thank you very much. Thank you. Thank you. Thank you very much.
