Beyond Secrets Management: Transforming Security in the Digital Age

Welcome, everyone, to our KupingerCole Analysts webinar, Beyond Secrets Management, Transforming Security in the Digital Age. This webinar is supported by Entrust, and the speakers today are Michael Loger, who is Director of Product Management at Entrust, and we have Martin Kupinger, I'm the Principal Analyst at KupingerCole Analysts. So welcome again, and before we jump into the content of this webinar, a little bit of housekeeping. We are controlling audio, so you don't need to care about it. We will run two polls during the webinar, and if time allows, we will look at the results during Q&A.

We will have a Q&A session by the end of the webinar, but you can enter questions at any time using the webinar tool at the right side of your screen. There is an area Q&A. There's also the poll section, and we are recording the webinar. We will provide the recording, as well as the slide decks, soon after the webinar, so that you have all information on hand. Having said this, I'd like to start with a poll, and this is more a very generic poll, but it's, I think, very important in the context of identity management, identity security, and what you are talking about. And that is quite simple.

How does your budget change this year? How will it change? Is it changing compared to the previous business year? So is it growing significantly, which we define as 20-plus percent? Is it growing slightly, 5% to 20%? Is it rather stable, or will it decrease by more than 5%? So we'll leave this poll open for a while, so you can respond to the poll. And then after one or two minutes or so, we will close the poll again. And while you maybe take the time for a poll, I'll already proceed a bit and have a quick look at the agenda of today.

So I'll talk a bit about more the generic topic of what we see as analysts on the secrets management market and how we see this changing, or where we see a need for change. And then in the second part, Michael will talk about rethinking secrets management and how this can be done and be supported. And then we have to, as I already mentioned, the Q&A part.

And again, the more responses you, or the more questions you ask, the better it is, because then we will have a very lively Q&A session. And that is always very valuable when we are doing a webinar. And it's a great opportunity as well for you to ask Michael and me about what you want to know in this area, because you have two experts on hand that can respond to your question. So let's start with secrets. And so a broad definition of secrets, broad in the sense of a broad IT or cybersecurity focused definition of secrets. So not beyond our sort of tech scope, surely. What are secrets?

Secrets are sensitive information that is used for security, I should be at, and it must be stored and handled securely. And the area we are really looking at is the secrets that are used for authentication, for cryptography, for all these things that are around securing communications, securing authentication, et cetera. And it encompasses humans, but also things and services, et cetera, to authentication, to APIs, to services, to applications, everything.

So the perspective we are, or the area we are looking at, are secrets that include even passwords, even while they're sometimes handled a bit separately, but certificates, keys, tokens, et cetera, in a wide range of variants, such as API keys, SSH certificates, 502 keys, X509 certificates. So this is just a bit of a sample.

So it's really this sort of, when you look at the lower part of the world, where we have a ton of secrets, where we see also new things coming up, where we, when we think about things and services also are facing a sort of a scale and scalability and scaling challenge, because it's not that just our users have an X509 certificate. It's we have services and APIs, and we are talking about, yeah, way, way higher numbers of secrets we need to deal with.

And it's always, I think, when we just simply look at, and I think we also can close the poll now, if we just simply look at this area of secrets, management of secrets, then we're always talking about an area that is sort of utmost interest and relevance and importance to attackers. So what is it what attackers want to know? It is the sensitive information secrets, in the sense of what I defined, are a very essential element of what attackers want to know, because this allows them to access.

This allows them to proceed, once they are in your network, to proceed further to more sensitive systems, to more sensitive information, to access information, to decrypt information, to whatever. So simply said, if you can't keep your secrets secret, you are at risk. And when I take a very simplified, and you also may argue it's a bit oversimplified, this picture, but in a very simplified perspective, there are a lot of secrets around. So effectively, what we're looking at is there's someone or something with an identity. It might be me as a human.

That might be a service that has a service identity. And from there, an application or another service should be a secret. So I want to use an application. I want to access an application.

Hopefully, there is a secure communication between me and the application, which is well secured, which means already we need some secret to secure the communication. This is very frequently happening in the background, but still, there's something needed that is kept under control. And this is, I think, a very, very important point already. To communicate securely, we need something that we need secrets. And then I also indicate to the identity provider, because the application says, hey, I want a bit of a proof that you really marked them.

And to deliver the authentication token in which way ever, and that can be directly or indirectly, depending on the authentication methods that are protocols, needs to be delivered securely. Because this is a very, very sensitive information. So also secure authentication, when I provide some sensitive information, worst case, a password, it needs to be secured. It never should run clear text over the network. It needs to be delivered securely. And then there is the application accessing another application via an API.

So we need a secure communication here to the next service, as well as we need a secure authentication at the level, not of a human in this case, but of something, so to speak, of service to service. And even in that very simplified picture you already see, there are a lot of areas where secrets are involved. And things can go wrong in each of these places. So there are so many, even at this very high and abstract level, so many, there's so much attack surface that we really need to be very conscious about, how can we deal with secrets and how can we keep our secrets under control?

And I think it's very important to understand this is a big, big theme, which affects all of your IT. When you're communicating with our servers and with a website, so we use TLS, there are secrets in. When we authenticate, there are secrets in. When we have API to API communication, there are secrets in. They are ubiquitous. And this is why we need good means to manage secrets. And as I already mentioned, when you look back to the list, it's a growing number of secrets, both by the types of secrets. So we have right now 502 keys and things like that, which are rather new.

And by the sheer number of them, because it's not just humans anymore, it's in a world where we have microservices architectures, a lot of API-based communications, this is everything at steroids, so to speak. So there are various numbers to ask, various questions to ask about secrets management. And I created a super simple checklist, which doesn't shoot for completeness, but which I believe highlights a couple of aspects to look at. And where I'd like to start is with a very simple question. Do you know which secrets you have in place?

So which areas do you need to look at from a security perspective? Where are these secrets? Do you at all know where across your entire organization, across all the applications used, all the on-premises and cloud services, all the use cases secrets are used? Do you know it? This is the starting point. You can't protect what you don't know. The second question is, do you know where these are stored?

And how, maybe, as well. So where are secrets stored? Is this really a safe way, a secure way of storing your secrets? And that is directly linked to whether the secrets are really secure. So is there something like an HSM or hardware security module used? Or are they more or less unprotected? And this is, I believe, very, very essential to understand. So which ones, where, how they are protected. And that also relates to who takes care of it. Who is responsible? And is this the appropriate person for dealing with secrets?

Or is it more a grassroots secret thing where someone started setting up a server and a bit of a vault to create secrets, for instance, in the application security space for secure API communication, et cetera, where the central security, the CISO department doesn't know about. While this might be some critical digital services that are developed for your organization, or things that run somewhere in the shadow IT, in the shadow cloud, it's a responsibility thing. And who creates and who deals with secrets should be capable of that.

And there must be a responsibility, and there must be knowledge about what is happening. And you need to put this straight. Because otherwise, you're at risk, you're at a huge risk.

And, you know, when you look at some of the upcoming regulations and some of the new regulations, then things like encryption play always a wider role. If you look at things like DORA, the Digital Operations Resilience Act for financial services in the EU, there's a section about encryption. Other regulations do it the same way. You need to be good in that, because otherwise you're also not compliant. Do you also know the current state? That's the other question. So are these secrets current? Are they well-managed?

Are they definitely secure in the sense of not already in possession of an attacker, all the things? Do you know that? And if not, then it's time to act. Because we are really talking about sort of the very core of everything in security. So this is, I think, something which is really important and essential to keep in mind. So there is something that can help you, and that is secrets management or key management. And when we look at key management, it's an established discipline.

We can learn from that for things beyond sort of the traditional key management domain, because we have good practices in place, but in some areas. But not in all. And when you look at key management traditionally, and I think this is the blueprint you should take when we look at secrets management, then this is something which is really run by experts in key management usually, by experts in cryptography.

And yes, these people are rare. Even amongst IT professionals, there aren't that many who are really savvy in key management and cryptography and all these areas. Key management usually works with high security, including hardware security modules, et cetera. It builds on established standards and protocols like Cayman. It builds on established processes. And this is the point. We need to do it for every type of secret. We need to understand who does it.

So responsible persons, people who are skilled securely in a standardized manner with processes that also, for instance, ensure that certificates are updated sufficiently ahead of their end of validity. And I've seen so many scenarios where whatever VPNs didn't work because secrets haven't been updated, or where SMILE certificates aren't updated on time, and signature and encryption of emails fails. So the question I think we also must ask ourselves, and this is maybe a bit of a provocative question, is it really a good idea to democratize Vodafone's secrets management, as we do in many areas?

So is it a good idea that someone in development can set up a solution that creates and manages secrets for a certain use case without alignment and integration into the broader concept? I think you can guess what my opinion on that is. I don't think it's a good idea. So what we need to do is we need to improve. We need organizational responsibility, and we need to implement this well, this based on defined policies, defined process.

I still see across cybersecurity, across identity management, across all these areas, I don't see enough proper work on policies, process definition on paper and quotas. It's important. It's essential. We need technical integration into the various domains, to the growing number of domains as well. We need comprehensive technical solutions where a vault and HSM, et cetera, are part of, but where we need more. We need governance. We need reporting. We need a full lifecycle management of secrets, including, as good as we can, sometimes there are some technical limitations.

For instance, invalidating retiring secrets. And last but not least, we need technical cryptographic excellence here.

Otherwise, we will fail in this core area of security. So having said this, this is a bit of my wake-up call on secrets management. Do it. And before I hand over to Michael, a quick second poll. And this is about where do you stand with secrets management? Which strategy are you following? Will you follow the secrets management? So is it more decentralized approach where you do some stuff in the PAM solution, some stuff as a key management solution, some stuff with whatever, a vaulting solution in the development space, et cetera?

Do you intend to strategically shift to an integrated approach, but it will take time? Or are you even shooting for a fast adoption of a fully integrated approach? Or do you just say, I don't know yet, or it's not applicable?

So again, we start a poll. We leave it open for a while. And while we do so, it's my time then to hand over to Michael for his part about rethinking secrets management.

Michael, so it's your turn. Many thanks for your introduction. And I fully agree that there's a lot to do, and the world will not get less complicated. Little introduction for myself. I'm Michael Luger. I'm the director of product management here at Antrust. And a little bit over the next 20 minutes, I'd like to guide you how rethinking key and secrets management, that in the end, both are the two sides of the same coin, should be handled in the future, and why we're thinking we need to have better products that we currently have.

So key secrets management is one part of Antrust of a far bigger encryption landscape. We are, in the end, one of the biggest encryption vendors on the planet. We do it for more than 50 years now. And we are mostly behind the scenes. So most of you are using us without knowing that we are existing. Key and secrets management, a lot of companies a little bit refuse to understand that this is the same. That in the end, we're generating keys to generate certificates. We're generating certificates that act as a secret. And this is, in the end, one big coin, and it's not two separate things.

Yes, we have still passwords, and still we have some sort of API keys that are simply a string. But in most cases, we are going to a TLS certificate where we want to work. We want to work with encryption keys like AS. We want to sign, verify things. We want to tokenize data, pseudonymize data. All of this is part of the encryption world in the end. And the point is, and Martin put it wonderful, there's not many crypto experts there. And for the rest of the world, cryptographic is a little bit like Black Witchcraft. A lot of people are scared.

Yes, most of us, when we started information science, had it during the information studies. But when it comes, what is the right algorithm, what I have to do, how I generate appropriate certificate or TLS certificate, what is perfect forward secrecy, what is in elliptic curves, and why is existing 20 different versions of them like ED25549. When you go to the weeds, it's a complex world. And the problem of the people is, is it what I'm doing here correct when you're not a really deep crypto nerd guy? Is it still correct that I maybe followed a manual two years ago?

Is it compliant with local regulations, local laws? And also, they are changing frequently. So we have this tool we have since 2022, ISO 2701 redesigned. And all of these questions is something you need to answer, especially when you have a company that handles critical infrastructure. This tool is there, DORA is there. So the requirements of the security regulations will not decrease.

They will, over time, increase. And you need to answer all of these questions. And I like a little bit to steal a quote from a customer that I talked on the last pre-pandemic RSA conference, and he went to the exhibition and say, Michael, here is no key and secrets management solution.

I said, why? There's dozens of vendors here, including us at this time. And he said, no, Michael, they sell graveyards. And I was a little bit confused.

He said, what do you mean? Look, on a graveyard, you have a name, a start date, an end date, and a origin. And this is what they sell me as key and secrets management systems.

Yes, they're doing technical things, but this isn't helping me, that there's no documentation. What does this key or secrets protect? It is just a key for a sequence for a test environment. Or does it protect my 2.5 petabyte Oracle database, where I really need to care about that this is done appropriate. And he failed, the story behind was, he failed utterly in audit, where the auditor points this correctly out.

He said, guys, you have a lot of keys and secrets, and they have also funny names, like the latest key, the brand new key, and the Friday afternoon secrets. And you have no clue what they're doing. And then the questions from the auditor was also, how the heck you're deleting crypto objects when you have no clue what they're doing? The answer was simply, when they're older, we delete them, but we keep them, but don't make them on the productive system available. And when nobody's crying for a couple of days, then they think, okay, it can be deleted.

What sounds like a plan for bigger companies that falls under financial regulations. And this was where I also come and say, we need to do better. And this is where I came up with how we need to redesign key and secrets management. First problem, there's a fundamental statement in IT security. If you don't document it, it doesn't exist. And the other point is, governments, in example, don't have a concept that you don't have a documentation. They don't understand when you can't decrypt sensitive data for governments.

They don't understand why you're losing data based on not finding the decryption key for a big database. And this shows also that I put here now the funds and awareness model, but there's also existing communist and RSA. It's called the maturity model in the end. A lot of companies have no processes or they have processes like we make all the two years of compliance audit. Sometimes they're promoting behavior changes. But in the end, what we all want is a level five solution. What does it mean? We measure 24 by seven. The current state checks is against policies.

And these metrics are based on what we allow, what we not allow, what we have to fix, and where we also have to improve the processes. These metric frameworks, you see it in all other industries. One good example is the car manufacturers where you have torque wrenches that are electronic and they not only guide the people about the torque that they have to put on a nut. And they also document it. So when things going wrong, they have the evidence. This was by manufacturer fast and appropriate. So someone else has to modify it or they find out it was a production.

Maybe something, some companies that building planes should be learned again. So what we did here at Antrust is we redefined key and secrets management. In older days, key and secrets management is, hey, I have a secure environment like a board, like Nature's M, and I generating keys, secrets, certificates, and I have a little bit access control and I supporting some protocols and I have a automated key rotation one time in the example. But this isn't answer the question that you can't distinguish between the two.

The question that you can't distinguish this is a productive key or this is a test key or this is a key that shouldn't exist at all. So what we want to have is we want to control the keys where they sit. We have a lot of regulations on the planet where a key should not leave the country like Swiss FEMA regulations. You want to have a decentralized risk management. So the keys should only be utilized and stores in the network, in the environment where they are needed.

But still, the T-level or the management level needs to get, I don't like this word, but I think it fits your best, a single pane of glass. What secrets, keys, certificates I have around the globe. And for this, I need to do compliance risk management and I need to enforce documentation. I need to know why this exists. And other analysts call this CDSEC, centralized, decentralized security. And they also told me this is the only security architecture they accept for the future. What does it mean?

You have a centralized visibility, but the sensitive objects still getting decentralized and not in a single pot where you accumulate all risk in one single bit, an example, key management cluster. And this is why we have also, we call it board architecture. And so we have boards for all use cases, secrets, keys, certificates, and the departments utilizing it. They're generating key secrets 24 by seven, but all metadata, but only the metadata, never the key or secret itself will be shared to a dashboard that we call compliance management.

And this is why we have a board architecture that we call compliance manager and where we manage the life cycle. So we see, I generated natively in AWS a new key or new secrets like an SSH certificate. And with this visibility, I can ask, please document it. And when I say, this is a test key, the system will remind me in two weeks, please delete the keys, that test key should only stay for two weeks in our system. And in another case, I create an encryption key for the big HR database. And the system will come back and say, Michael, this is not the right way.

For this, we want to have really not only bring your key, we want to enable hold your own key. What does it mean? We get a higher security requirement for this kind of data. So I directly prevent, the system prevent me to do the wrong things. So the questions from the beginning, is this right what I'm doing will be checked 24 by seven. So the compliance manager does a lot of things. So first of all, for the secrets management, where we're talking about, it monitors all these secrets, certificates for the target solution.

But it does as well, where are we coming from as AntWRST, from the classical encryption technologies. So database keys, KMF keys, VM encryption keys, IoT devices, certificates, and so on and so forth. The classical secrets management vendors, understand that a secret is more than just an API key and a little certificate. They starting to migrating their products in our direction. The point is, our direction with the strong encryption knowledge that we have for more than 50 years, is a combination of the security and the security of the product.

So we have a lot of security and we have a lot of security for more than 50 years, is a complex one. So they're struggling and the progress is also slow.

For us, the other way around, I'm going for as a strong security vendor with highly FIPS certified HSMs with up to FIPS 140-2 level four, and come criteria certifications, where we protecting governments, big companies, enterprises, banks, and financial institutes around the world. For us to do additional secrets is easier than the other way around. And then the compliance management. This is something that people really oversee. We have hundreds of regulations around the globe.

We have data escrow regulations, even in Germany, when the government comes to your company and said, I want to have this decryption key, you have to pass it. You can say, I don't want to do this, but the result could end up that you're ending up in jail. In South Africa, the law is that you can up a 10 years for jail. So what does it mean? In most cases, you don't want to share keys globally. You want to keep the local, to fulfill the local laws. So a key in South Africa should stay in South Africa. Key in Germany should stay in Germany, and a key in UK or US should stay in this region.

But you as a global management, you need to understand the compliance and how this does. And what is a wonderful function of this compliance manager is, the compliance manager has a very complex policies that translates this crypto-nerdic technical requirements, the compliance regulations around the globe, and something you as a C-level can understand. It's translate all of this. So you can say, I don't care about the policy and what is ED25519, and I don't care that in Germany, BSI by end of 2023 retired RSA2K keys. What I see is Germany is less comply in 2024 than it was in 2023.

And then the technical guys will say, yes, sure, we are less comply that we have too many old RSA keys. Yeah, please make a process to outface them and replace them with proper keys that will fulfill BSI regulations. Another thing is risk management. Our tool translate every single object to a risk score. We have a lot of factors that comes to this risk score, how well protect this keys.

Aging, even when it's just a cryptographic object, it shouldn't be aging, but the aging. So what we're calculating is it increases risk over time, especially when these keys are exposed to a Windows system, an example. And there's regulations around the globe that tells how old a key maximum should be. So also this will be part of the risk score. And then based on the documentation, we force people to fulfill it. We understand also what does it keep protect. So test keys that doesn't fulfill RSA 4K, it's maybe fine on the test system, but it's not fine on a productive system.

And the risk score helps companies to focus where they should mitigate first, that this risk score is a guidance. And you as a manager, you don't need to understand why this risk score is really high. This is a target of the guys that needs to fix it technically on the endpoint solution. And maybe also they found out, hey, yes, the score is high, but we can't fix it. Based on the technical problem, the solution can't deal with better cryptographic algorithms. Then you can document the exception. So a proper exception handling is done.

That you accept sometimes risk, but this needs to be as well documented. And this is really important that you get this information and that you do more than just generating technically cryptographic objects around your company. That this is the clue for everything. So the compliance manager manage the compliance and all of the technical integrations helps you that you can implement what we called zero trust strategy or an older word, it was called enterprise encryption strategy.

This means that you enable the people to have secrets keys, but this on a standardized process in a secure environment with secure processes. And this is what increases the security of your company are quicker and far better than anything else you can do. The threat detection, intrusion prevention, everything is nice, but then your fundamentals of your security, and this is today with falling parameters, this is encryption. There's no way that you can implement real security. So what our platform is, it's a cryptographic management solution. And the compliance manager is a translator.

So we collect data, we aggregate the data and we visualize the data in an easy, consumable way that you'll see compliance, risk, documentation, and can establish secure processes. And this is really, really important. And it gets more and more important. This is also that when we're talking with analysts, with big customers, they said, guys, your solution is the first solution I saw that gives me hope that I get control about all those millions of small, tiny crypto objects. That this was where a lot of companies said, I simply gave up, there is no tool out there.

And this is why we built this tool. We want to give back the control about your environment, IT environment on a cryptographic level. And this is also why Kuping et al put an analyst on our secrets management solution. And we get awarded for the market champion and the market leader. That what we want to do with our platform is really leading the industry with a new approach. We saw also the first attempts from the competition to copy us in this way. What is nice, I think the biggest compliment that you can get is when the competition tries to copy you.

That with our unique approach to measure metadata about cryptographic objects, regardless if it's a password, a sequence, a certificate, a key, you get really the control that you deserve. And then this is what we call key control platform with a compliance manager. You get a unique dashboard. You get absolute unique compliance and risk management. And you established now safe repeatable processes that one of the things is we don't tell you you have to utilize and bring your own key or hold your own key for the cloud example. You don't have to utilize us every time.

We only want to have maybe a connector and see what's happening in the systems. And we tell if it's appropriate or if there's a more secure process you should follow based on the sensitivity of the data behind. And that's my 20 minutes. So I'd like to get back to Martin.

Thank you, Michael. That was very insightful. And definitely, I believe there was a ton of very important information and a broad scope you've presented here. So let me quickly share my screen again. Here we go.

Okay, so let's start with our Q&A then and look a bit at the questions. We already have a couple of questions here to the audience. You can at any time enter additional questions. There's also an option to vote for questions. So which questions you feel are most relevant to you. I want to start with one, which is probably being one of the hot topics in the space. And that is, do you have any recommendations for organizations embracing crypto agility and being prepared for post-quantum cryptography? Post-quantum is currently a very big topic for a lot of companies. And there's two approaches.

We support both. The first approach is to scan your networks about what you have as a crypto environment and then tell where you need, an example, RSA keys or public key mechanisms needs to be replaced with newer ones. Older encryption standards are outdated. When customers utilizing our key management solutions, they have some benefits. They have a 24 by seven knowledge about all keys. So our compliance manager can simply give you in a fraction, real time, how you comply with post-quantum and helps you to be post-quantum ready.

For most companies, it's maybe far horizon, but every company that develop hardware, an example today, or has a long-term project, you need to be prepared. That we're talking an example of car manufacturers that they said we need to support the cars for the next 20 years. And post-quantum is for us a topic that a car is now a mobile payment system. And this needs more security and we need to be capable that the hardware needs to be capable to deal with the far more complex post-quantum algorithm.

I would care to say in this space also being able to exchange secrets in a flexible manner, which is not easy for disconnected or partially connected autonomous systems and all the hardware side. But I think we still have a long way to go there as well. I think we need a lot of improvement in many areas. So it's definitely a very important part.

Yes, I think you put it right. Post-quantum cryptography starts with knowing what you have and what you need. Exactly. To keep under control. I think this is always the starting point. Next question I want to pick on here. We have a couple of words here already. What are the best practices of centralizing secrets management? You talked a bit about it, but maybe you can emphasize or can talk about this a bit more further. I could imagine, so this is the question I continue, that some customers might have multiple solutions in place. Probably many of you have.

The secrets manager for workloads, Azure Key Vault, HashiCorp Vault, et cetera. Exactly. This is one of the things that, this is also why it's not there yet, but why we're planning to integrate all of the third-party vendors as part of the compliance manager so that the compliance manager can understand what secrets you have in the HashiCorp Key Vault, what you have in AWS secrets vaults, what you have in Oracle Key Vaults. We want to support more and more third-party stuff. On our own solutions, you get a full control. We have also this vault architecture.

For secrets, the best architecture still is have a vault locally where you need them in front of your Kubernetes environment. Don't have a big fat solution that connects your entire company to one solution. That this is highly risky. That what you're doing is against every compliance law, you're centralizing risk. And this is not what you're doing. And simply imagine you have one system that controls all secrets and certificates and keys around your entire company.

You want to do something simple like a red team exercise and you want to shut down and reboot the system, find the maintenance window and find the error. As my daughter would say, find the problem. Yeah. But I think it's also important to be very clear, don't centralize the secrets, but centralize the approach how you deal with secrets. And I think this is the line to draw. So you must understand which secrets you have. You must have consistent processes in place, consistent policies, and all this stuff. And as German, we love processes.

So I think for us as a German, it should be easier than anybody else to establish these processes. It's still something where what I observed that there are still many organizations a long way to go. And to do this really properly. And I think my experience is the time spent for process work, if you do it right, is always well spent because it will save you a lot of time later on for fixing problems, for changing implementations that don't work due to the wrong process, et cetera. So I think it's a well-spent time.

This is very important, but I think also it's very important to have something which helps you dealing, like you pointed out, with various solutions, and it ensures that each single of these solutions is secure. It's not only secure, it's also one thing people underestimate is what happens when your solution is not fitting your requirement anymore.

Sometimes it's a change process to change this solution to a newer one, and more modern ones and more scalable ones will hurt you more than you saved as money with the cheaper solution, or even worse, a manual process with an Excel sheet that I saw still in a lot of companies. Yeah. There's another very interesting question. I feel as organizations migrate to the cloud, some are interested or obliged in maintaining control of their keys using approaches like bring your own key or hold your own key. So does Intra support, for example, AWS, XKS, or other types of hold your own key?

Absolutely, we support it. One thing we do a little bit different than the competition is the competition tells us every time, hey, bring your own key and hold your own key is the only solution you should deal with, and they have to do it because they have no knowledge what is sensitive and what. On our approach, where we ask the user, what do you protect with this key? We accept also natively AWS-generated keys and can say, okay, it's fine that you have this key. It's documented. It's no use case behind that really requires hold your own key or bring your own key.

It sometimes comes also with a cost to have these keys. And in other cases, we say, this is definitely solutions where we want to have hold your own key and where we have Microsoft Double Key Encryption or Amazon XKS or GCP, AQM. There's these technologies exist. Use it when you need it, but when it's a test key and someone wants to play around encryption, maybe bring your own keys a little bit overshoot.

Okay, great. What do you see as the challenges in dealing with long-term storage and security reveal of keys? This is one of the most interesting questions, in my opinion, that this is also why we generated the Compliance Manager that sometimes you're generating keys and then you're deleting keys because you don't need them anymore. And the evidence is this key ever existed is vanished. Sometimes you delete an entire vault. You maybe replace also key management system with one with another. And the evidence of this key is gone.

But now imagine the situations you have data that you really need and they have been encrypted and you can't find the decryption key anymore. And this is why we generated also the Compliance Manager that the Compliance Manager acts also as a long-term repository. So you can ask this Compliance Manager, I need the HR key from 2017 and it will tell you, yes, this is a dormant key on a dormant vault. And the latest backup file is this name. So you will find in your backup systems, the backup file of this vault.

So you know what to restore and where to find this key pack that long-term the requirement is, this is biggest problem of a lot of IT companies that enterprise companies have a horizon of 10 to 20 years based on government regulations. You have to store financial data for at minimum 10 years. Some companies have to store data for 20 years. And today we want to encrypt all data and we don't want to have pretext data lying around on a tape or something else in a bin that we want to know that this data are well protected.

But with this protection comes a requirement to properly secure these keys and to have a long-term repository without good luck to find your key. That they have bad cryptographic names, mostly a UUID. They don't have any information inside. You can't look inside a key. You have to look at what it was supposed to do. This is a drawback of keys, how they are defined. So you need a system that connects this key to what does it protect. And without the documentation, absolute no chance.

Okay, great. So I think we can take at least one more question here. What can key control offer in situations where data sovereignty is required? I regenerated this world architecture that I have been in this cryptographic area for more than 25 years now. And I saw it in older days also centralized key management solution. And the people were happy and said, it does all the functions. But then it comes that someone in France find, hey, this violates the law. I can't store a key in Germany.

Okay, even when it's a false statement, it takes you and the lawyers weeks and months to find out this is a false statement. And then you find out in Switzerland, it's a true statement based on the FEMA regulations. On Luxembourg, it's the same. And the data sovereignty is important. And this is why our approach really with the world architecture is, have the keys sitting in front of the environment where you need it. And don't share them around the globe. Don't connect to a system on the other side of the planet to receive a key.

The key has to sit in the country, in the location, in the network. Otherwise, you're also sacrificing your network. Latency is another topic that you have to deal with when this key management is in the cloud. In example, you have an on-prem database to protect. It is without a question the most, or the most secure solution that you can have to have the keys locally protected. The point is, a lot of vendors have this architecture. They have the boards in front of you, but there's no management system above. So the administrators are left behind and alone and doing what they want.

You mentioned it in your presentation, Martin. You need a governance solution that is capable to see that the administrators are doing the right thing. One of my friends, he's a CISO from automotive vendor. And he said, Michael, I'm not interested how or what tool the people using in this certain country. What I want to know is that when they're doing encryption, key management, secrets management, they follow our company processes.

And at this time, there was no tool that makes this visible that when they're using local tools, they have you to give you access to the local system, what means you act as an administrator and you could be an intrusion. With our solution, the board never shares any keys or secrets outside it, but it shares the metadata. And with our metadata collection, you can share now the data to a central board based. It's only the evidence that this key exists.

It's collecting the documentation about the key, but it never have any possibilities to create, delete, rotate a key or secrets or get any information out of the secrets. And this is what is a real data sovereignty and it doesn't sacrifice your network security, your infrastructure security.

Thank you, Michael. And with that, I think we're at the end of our today's webinar.

Thank you, Michael. Thank you to all the attendees for- Thank you. And providing or asking questions. Thank you to Entrust for supporting us with this webinar and hope to have you soon back at one of our other upcoming webinars and events. Don't miss EIC by the way in June. Thank you. Thank you. Have a great day.