Crypto-Agility Starts Here: Protecting Identity in a Post-Quantum World

Hello and welcome to another Kubernetes Core webinar. My name is Alexey Balaganskiy. I'm the lead analyst here at Kubernetes Core Analysts, and our topic for today is Crypto-agility starts here, protecting identity in the post-quantum world. And my distinguished guest today is Brian Nilsson, the CEO of Quantum Core Institute.

Welcome, Brian. And can you please tell us about you really quickly? Sure. So my name is Brian Nilsson. Thank you very much, Alexey, for introducing me. I'm the CEO of the Quantum Core Institute. We are a quantum risk advisory firm. We've published a standard on allowing people to look at what they need to do in preparation for quantum. And one of the topics that we're going to be covering today, of course, is on crypto-agility and how it relates to organizations and what they need to do. Great.

But unfortunately, before we jump into the topic, we have to spend just a minute on housekeeping rules. So as usual, everybody is muted, so we don't have to worry about microphones. We are recording the entire session and it will be published on our website as an on-demand webinar recording.

Tomorrow, the latest, along with the slide deck. This whole webinar is actually one large Q&A session, if you will, but still, you are very welcome to submit your questions, too. You can use a special questions tool of the Livestorm control panel for that. And I guess without further ado, let's jump into the agenda, which is, again, very simple. This is not the standard webinar. This is just a fire chart, if you will. We have very few slides and we will be talking about them, probably disagreeing about some stuff and then trying to find a common solution.

Our goal is to establish not only what crypto-agility actually means, but also how to apply it in practice for post-quantum cryptography specifically, but not limited to it. And by the end of the webinar, hopefully we will give you some practical advice of where to start right now.

And again, please submit your questions at any time. We will have time for those by the end of the session. So this picture, for those who are unfamiliar, is a Roman history museum in Pisan in Germany. I like it very much because I think it's a perfect visual metaphor for what cryptography has been for decades. Because usually for at least 40 or 50 years, probably even more, cryptography was set up once, configured and let it run somewhere in a cellar, forgotten, unchanged until something breaks or at the very least an auditor comes and starts asking inconvenient questions.

So this fancy glass building looks very modern, but inside you probably can make out the remains of the Roman buildings. And of course, there are absolutely no surviving blueprints for those. And this is exactly what our enterprise cryptography looks like. But why do we have to suddenly, suddenly everybody talking about crypto agility? Was it quantum?

Well, yes, to a degree, of course, because everybody's talking about quantum computing, how those computers could probably appear overnight tomorrow, or maybe not. Maybe it will be in 10 years, nobody knows. The problem is it's a very hot topic. Everybody has an opinion. And everybody finally decided to prepare for the occasion.

However, we do know that bad things happened to cryptography before as well. Those who worked in the industry longer remember things like MD5 and SHA1. They were just duplicated because they were too old and small and easy to crack, just like TLS 1.0 has been duplicated. You probably remember Heartbleed, which was like 12 years ago, if I'm not mistaken, where it wasn't actually a cryptographic algorithm problem, it was an implementation problem. But it was so huge in scope that 12 years later, it has not been completely fixed, as far as we know.

So there are still unpatched systems 12 years later. And of course, the emergence of quantum computing is just a much bigger, scarier event. And of course, it comes with a much stronger scrutiny from the regulators. So this is probably the biggest difference.

Brian, your job basically is talking to people about this urgent issue. Is there a deadline and how do we approach it?

Well, you know, is there a date? It depends on who you talk to. Is there a deadline?

Well, we have examples, both in the US and in the EU, about deadlines that are happening. For example, DORA has created a number of deadlines for us to actually start to look at.

But, you know, I think that what quantum did is it made the existing problem kind of impossible to ignore. You know, we've looked at cryptographic change, and we recognize that it's not new. We've been through, as you pointed out, SHA-1, the deprecation of that. We have migrated versions of TSL, main TLS. We have dealt with vulnerable libraries, expired certificates, weak cipher suites, compromised keys, and algorithms that simply reached the end of their useful life. And every one of those experiences taught us essentially the same lessons.

That is, changing cryptography is much harder than choosing cryptography. An algorithm might be changed in a standard document fairly quickly, but changing it across thousands of applications and devices, APIs, suppliers, identities, and business process is an entirely different matter. And that's why I think post-quantum cryptography is best understood as a forcing function. Quantum didn't invent crypto agility. Quantum revealed that we really kind of desperately needed it. And now the clocks matter. There are two clocks that are out there. One is the clock of when is it going to arrive?

And the second one is how long is it going to take for us to migrate? You know, these clocks are being asked. We're asking organizations to migrate away from these public cryptography that may eventually be vulnerable to a cryptographically relevant quantum computer.

NIST, as an example, has standardized the first PQC algorithms and is explicitly telling organizations to begin migration. But I would make one distinction, and that the objective should not be let's survive quantum migration. The objective should be let's build systems that never again require a heroic effort simply because cryptography has to change.

And, you know, that is the essence of crypto agility. And if we do this correctly, post-quantum migration becomes the last massive cryptographic migration we approach as a kind of a one-off emergency.

Well, I can give you two extreme examples. One, those who are old enough to remember, was the famous year 2k issue. It was huge by the end of the last century, if you will. And when the date actually came, everybody was disappointed.

Well, nothing has happened. Where all the money went into?

Well, that was exactly the point. There was so much of long-term preparation and a lot of hard work of all the people around the world to make this as smooth as possible.

And, well, nothing happened. It was a non-event, if you will. And the other opposite extreme we have, for example, the hardware problem.

Again, 14 years later, it still has not been fully addressed, even though compared to our current challenge, it's so tiny, it's just one library. Would you rather have your next challenge be the year 2k scale or the hardware scale? I think everybody... I think it's kind of both. We're experiencing both. One is that we're looking at a situation where we have enough time to start to make some of these changes, but at the same time recognizing the difficulty in implementation. And those two are very different objectives. One is a recognition and the second one is really the implementation. Right.

However, I want to highlight another important distinction. A lot of people just kind of glance over when they're talking about PQC. Quantum computers, when they actually emerge and start cracking encryption, they won't be actually targeting the symmetric traditional encryption. They will be targeting the asymmetric one. So your data, which is encrypted, sensitive or caller recipes and financial records and whatnot, are fairly safe. They won't get decrypted soon. But what would happen, a lot of stuff will get forged. Signatures, identities, credentials and so on.

So actually, the biggest challenge here is not losing your data. It's about breaking your entire identity ecosystem. And I think you gave a great presentation about the topic at our EIC conference this May. So can you maybe talk about that in more detail?

Well, sure. You know, one of the things that I gave and spoke about was what really needs to be protected in a post-quantum world.

And, you know, most conversations always begin with encryption. The question is, what happens when quantum computers can decrypt things? The important part of that is recognizing that there's a part of it that is the harvest now and decrypt later.

You know, someone can collect encrypted information today and potentially decrypt it years from now if the cryptography protecting it becomes vulnerable. But confidentiality, and this is one of the things that I covered in that email, was it's the other half of the story. And that other half is the authenticity. How do we know that you are really you? And how does a device prove its identity? Or how does a workload authenticate itself to another workload? Or how do we know this software update came from, for example, Microsoft rather than someone pretending to be Microsoft?

Or how does a browser determine that the server on the other end of the connection is legitimate? You know, these questions heavily depend on digital signatures, certificates, PKI, code signing, credentials, past keys.

I mean, the list goes on and on. The bigger statement is quantum potentially threatens portions of the digital trust architecture, which was really the key of that conference in Berlin, the EIC conference. And that is that, you know, quantum, it again, threatens portions of the digital trust architecture. And that really kind of changes the conversation enormously, because confidentiality failures expose information. Authentication failures allow someone to impersonate people, machines or software.

And can you imagine a world where you can protect the content of a message, but you can't reliably prove who sent it? You know, that's really the key. This is a broken system of trust. So organizations need to inventory, not simply what they encrypt. Let's not run ahead. We will get to that. We will get to recommendations. But I want to close this introductory part with just one quick statement. Confidentiality is important, but 99% of your confidential information comes with a very short expiration date.

Some information is on the relevant for hours or even seconds and then anybody can steal it and we won't care. Identities, however, are too often too long term. And this is probably the fundamental problem you were just alluding to, especially when we are now in the age of machine identities and agentic identities. We are coming to the problem of scale versus long lived credentials. And this is where the entire system breaks. Because one small compromise can break a lot of systems and it can continue unnoticed until you finally start noticing that something bad is actually happening.

While tripping absolutely no security system because each access is still legitimate. It looks like that. So how do we address that? That's kind of the meat of our today's discussion, if you will. And we have to start again by defining what do we actually mean by the term crypto agility in practice. A lot of people think, yes, you have to retire the RSA and replace it with the newly adopted NIST post quantum standard and you are done. You just make sure that you do it ahead of the deadline and then you are safe and secure and every auditor is happy.

You put it into a report and you file it and forget about it for 10 years. Well, unfortunately, this cannot be further from the truth.

And yes, we already alluded to it earlier, but just to reiterate, crypto agility is much more than that. It covers not just the algorithms, but also the parameters, the implementations, all the software stacks and hardware stacks as well around those implementations, configurations, negotiation processes. And of course, the entirety of keys, certificate and infrastructures to manage those. And lastly, the thing that a lot of people forget about completely, the processes.

The processes, of course, involve humans and especially they involve teams across different business divisions, companies, partnerships, alliances and industries. And the bigger those groups are, the slower the process can be changed. So crypto agility is not a product, it's not an event and it's not a single replacement. I would agree. It is a process, it is a journey. And I hate to say it, it's kind of like zero trust all over again, but at least we can give you a much more practical recommendation how to achieve that goal. I would agree.

I think the biggest problem is exactly what you just pointed out. And that is that crypto agility is not just algorithmic swapping. It's actually dangerous because when you think of it just that way, you misunderstand what the problem is. And you pointed out all the areas where that misunderstanding that is. And that is that if you have a cryptographic stack on one level, you have the algorithm and then you have the implementation of the algorithm.

But the protocol, as you pointed out, uses the keys, certificates, libraries, APIs, there's configuration, there's hardware, there's other dependencies, policies, as well as lifecycle management. And finally, the people and processes responsible for changing it may or may not understand all that. One of the things that you pointed out and one of the things which is agentic AI. A lot of the problem with agentic AI is that there's no tracking of the agents. So there's limited identity, there's no accountability, and governance models just rarely, rarely exist around that.

And if you have no ability to actually manage that, sometimes people are looking at it and going like, I'm issuing a certificate to a server. But when do I refresh that certificate? And so as a result, people are not recognizing where it is being done. And so I kind of use a simple test. It's kind of a question is, if I told you today that one cryptographic component in your environment had to disappear within six months, could you identify, and this is the thinking process for the organizations, could you identify everywhere it exists? Do you understand what depends upon it?

And could you replace it, test the replacement, and prove the migration was complete? The answer is no, you don't have crypto agility. And of course, you have to also agree all those changes with your partners and regulators and whatnot. And if you are an international company, then it all multiplies by at least a single order of magnitude, if not multiple ones.

Yeah, and I think one other kind of definition related point I would like to make specifically before we continue that agility is not the same as flexibility. Because a lot of people think, okay, I will now have to support 20 different algorithms and standards. And I will define a complex logic of falling back if something is not supported. And if I can actually negotiate a successful cryptographic process with every peer, regardless of what they can or cannot support, then I have achieved the ultimate level of agility.

No, you have not. You have achieved the ultimate level of fragility.

Because, again, a single issue in some of those 20 plus implementations you have to maintain can ruin the entire building, if you will, the entire architecture. So again, agility is definitely not the same as flexibility and this will be important later when we will be talking about hybrid implementations. Right.

So yes, crypto agility, the way I tried to define it just earlier today is the ability to adapt quickly and safely, which is probably the most important point here. It's not a product. It's not a migration. It's a state of mind, if you will.

So, before we actually start doing all those changes, how do you, as you just pointed out, you have to be sure that you actually know what's going on and what depends on it. How do we do that?

For that, you have to answer basically these three questions, which I have included on the slide. What you have, we have to inventory everything.

Then, as Brian just pointed out, you have to make all the dependencies. But more importantly, if you actually want to achieve that migration in a reasonable amount of time, you have to prioritize. So you have to know what you actually use today or daily and what can wait a little bit. Because if you start with a random low priority thing, your crypto agility journey will be too long. You will definitely miss all the defined deadlines. So can you maybe discuss a little bit in more technical detail? So what is it exactly that's included into this inventory and dependency mapping?

Well, I think that there is a tendency among organizations to fool themselves as to what they have. They'll come out and say, we've created a cryptographic inventory.

Well, that's great. The questions now, as you point out, is now I want to know whether that inventory lets you make a decision. Knowing that, say, server 642 uses RSA, that's interesting. But knowing that 642 uses RSA for a certificate that authenticates an API used by, say, 17 applications, including, say, a payment system, it's supplied by a vendor whose current protocol doesn't support PQC, is actually actionable information.

Now, those are very different things. So discovery has to progress through several layers. The first one is, what do we have? What cryptography do we have? The second is, well, where is it? Then what depends on it? Who owns it? And then how difficult would it be to change?

When we start to look at things about migration work that makes cryptographic visibility and inventory a foundational part of PQC migration, the idea is to specifically focus on comprehensive cryptographic inventories and maybe using those inventories as a guide for migration, as well as, as you pointed out, risk prioritization. That's where automation becomes important. Our modern environments change constantly. Cloud services, they appear. Containers disappear. Certificates rotate. We get new libraries that are being deployed.

Suppliers, they push updates. When we start to think about it, a spreadsheet created in March can be a beautiful document, but dangerously wrong here in September. The real objective isn't producing an inventory to me, and the real objective is to produce a decision-grade. And this is really very apropos to what you actually use, and that is, it's to create a document of decision-grade cryptographic intelligence. We can look at an environment and determine what needs to move first, and then that's the difference between documenting cryptography and governing cryptography.

I think it's really important to highlight that an inventory is not a spreadsheet, it's not a static asset, but in a way, it's not even a list of all the certificates and keys and stuff you have, because at least changes probably weekly today, which will eventually migrate to daily changes, maybe even hourly. It's largely ephemeral, and it's actually a great thing. If your entire cryptographic inventory were ephemeral, it would be so much easier to fix. The problem is, it's not.

Too big a part of it is not just old and long-lived, it's nearly impossible to change because the hardware device is no longer supported, it does not have enough CPU power or memory to actually deploy a new calculation bit, if you will, to upgrade it. So how do you deal with all of the huge blocks of technical debt in cryptography?

Well, as you alluded to earlier, one of the biggest things that quantum-resistant algorithms do is that they've created signatures that are massive in comparison to current, like RSA or ECC. I have seen documents that suggest that they're essentially 31 times as large.

So really, one of the questions that I guess what you're asking is, the interesting tension in the entire crypto agility discussion is, we want flexibility. And you used the word fragility when we created it kind of incorrectly, but we want flexibility. But flexibility in itself can introduce complexity, and complexity often is the enemy of security. So crypto agility can mean, can't mean, I should say, to support everything. Good crypto agility is controlled adaptability. We want cryptographic decisions abstracted away from application logic, wherever practical.

And we want centrally governed policy rather than cryptographic choices scattered throughout thousands of lines of source code. We want automated certificates and key lifecycle management. And we want short-lived credentials where appropriate. And I particularly want to eliminate hard-coded cryptographic dependencies. But every abstraction layer and negotiation mechanism must itself be secured. We talk about hybrid.

Well, hybrid classical and post-quantum cryptography is a great example. Hybrid approaches can reduce the transition risk because they're not immediately batting everything or betting everything on a new mechanism. But hybrids also introduce additional complexity, larger handshakes because you're doing it literally twice, interoperability issues, more code paths. So there's a legitimate debate here for sure. And we will get to that in a minute. But before we move to the next slide, I want to kind of point out one other thing.

Of course, everybody is now talking about the Seaborn cryptography bill of material as if it's somehow the same as inventory in your cryptography. No, it's not.

Again, I think we are repeating the same mistake as we had before with vulnerability scanners from the traditional cybersecurity era. I distinctly remember a company saying, I just ran the best of breed, the most thorough vulnerability analysis of my entire enterprise IT. And I have 2 million findings. Where do I even start fixing them? And the same would happen inevitably with something like a Seaborn. Having a full list, first of all, it's kind of pointless because you don't know where to start fixing it. And second, it will be outdated the next day, probably.

So we have to avoid any kind of traditional static approach to anything, whether it be inventory or dependency analysis or anything else. I think you said exactly the right word earlier, it should be policy based. Even better if that policy somehow works the same across the entirety of your IT infrastructure, regardless of the specific system or standard protocol. And even better if that policy can be declarative. You just basically say, I want to be compliant and BQC ready and whatnot. And somehow the set of tools would figure out how to implement it across your entire IT. Can we do it today?

No, probably not. Not even tomorrow. But we have to strive to that level of simplicity and abstraction as an end goal. Is it a feasible goal? allows for organizations to adapt, be flexible, and manage what their risks are. Because part of the biggest problem that we almost eliminate from it is that we get caught up in just the idea of encryption. The reason why we're doing this is because there is risk associated with that. And that's really what we're trying to manage here is what is our risk as an organization? I often say that BQC is really three windows.

One is the window of the past, which is kind of like the Harvest Now decrypt layer. The window of the present is identity, and the window of the future is payments in terms of how we do it.

And again, a lot of this stuff all happens simultaneously. And that's where our risk management is. But it's governed by the two clocks that I referenced at the beginning. And that is, when does algorithmic cryptography fail? When can it be decrypted? And the second is, what are we doing to prepare for that eventual day? And those two clocks are ticking simultaneously. Right.

So again, the clock is ticking. Everybody has to start doing something. Probably yesterday. Today is the latest. So where do we even start? What to do now?

And again, here we are coming to the big debate, if you will. We have the same premise. In a sense, we actually want to fix the cryptography issues. We want everybody to achieve that.

Again, for the sake of simplicity, let's continue calling it post-quantum cryptography, even though we said the quantum is not actually the biggest challenge. But how do we achieve that? And in a way, the regulators kind of give us different guidance. The United States says basically, get rid of all your technical debt encryption as soon as possible. Go pure by the deadline. If you have too much flexibility, you have too big a window for error and somehow exploitation. So hybrid is quote-unquote bad.

European regulators are actually explicitly using the term hybrid in their guidance and say, no, you have to go hybrid. You have to support both implementations, because post-quantum schemes are somehow not yet mature enough or adopted universally enough to run on their own. Some country level regulators outright tell you, you have to support both. Where are you, Brian, on this? I know from our past discussion that you are on the US side, obviously, because you're based there. But do you see any way somehow to put these two approaches into a single one?

Yeah, I look at both of these approaches. Both of them have merit and both of them have consequences associated with it. I think the European approach to a hybrid solution is a faster solution for achieving some implementation of new quantum-safe or quantum-resistant cryptography. The problem that I have with that, of course, is that they're going to have to do it again. So you're really going to be doing two migrations. The other side of it is, as the United States go pure, well, that's just some – maybe it's a leap too far.

Can you actually go from RSA and ECC all the way to pure quantum algorithms? Those are problematic. So does it mean that it's easier? One of the things I said earlier is complexity is generally the problem impacting security. So I think that the go pure has its benefits, but also a lot of its expenses, the liabilities associated with that, as well as the European hybrid solution, which is really having to do things twice. Right.

So I guess we could probably argue even further, and I actually have a separate document, just in case anybody after the event would ask for more technical details, which goes specifically into all those arguments for and against both approaches. But to put it really simply, at least the way I see it, and I have to confess, I am probably much more a theoreticist than you, Brian, because you deal with customers and I only have to do webinars and tell how it's supposed to be working.

The way I see it, the whole discussion misses the point in a way, because crypto agility in the end actually means that you don't have to make this hard choice. Ideally, if you say, I am truly crypto agile, you can do both, or you can change your mind overnight and implement something else.

Of course, it's very difficult to achieve and probably not a lot of real life companies can do and can go that far. But is there a way to somehow kind of reconcile these two approaches and at least plan your journey ahead in a way that you minimize the effort so that you avoid this kind of double effort. So the problem is, it's double effort now. You never know what happens next year. Maybe there will be another wave of new requirements or changes. And what if somebody compromises the standard which was just adopted, you would have to upgrade once again.

How do you get prepared to this unexpected, completely unexpected events? How do you come prepared for those worst case scenarios?

Well, I take this from the perspective that this really is a conversation of engineering. We can look at post quantum algorithms and how they behave differently, say from RSA or elliptic curve cryptography. As we pointed out, key sizes can be different, signature sizes can be significantly different. The handshake behaviors between them, they change. Bandwidth requirements can change. Memory usage can change.

Really, we can literally go down the list, smart cards, mobile phones, industrial control systems as having things that we have to address. But I think it gets back to the question that it's an engineering portfolio. It's an engineering problem. Different algorithms and configurations make sense for different workloads.

Obviously, we're going to find both currently and in the future that the algorithms that we are using may or may not be as cryptographically safe as we thought. Having the crypto agility, the ability to change these things is going to be paramount to the success of an organization in protecting its values, whether it be the identity of its people or whether it's the data or whether it's payment systems. All of that needs to be done.

To me, it's just a simple engineering question. How do you go about it?

Now, while the solution is an engineering question, I think the question for prioritization is a governance issue. How do we choose what to prioritize? Once we've got that answer, then the engineers can go to the solution. It's very important to draw this distinction because which algorithm you would have to choose today or tomorrow or next year is a completely different decision from how do you change your entire business process and governance policies and rules to be able to afford those changes of engineering solutions in the future.

I think this is where, yeah, you just said there is no single answer to everything in post-quantum cryptography. But where should we be looking for those answers? What are the things we have to cover? Can we just fix one thing or three things or is it more like 300? It's probably not 300. It's probably 3,000, 30,000, 300,000, depending on the size of the organization. The question is not just whether we can replace it.

Obviously, a software algorithm can be easily swapped in and out much easier than, say, a hardware system. We want to think of ourselves as dealing with this from what they refer to as a greenfield system. Most enterprises don't live in the greenfield system. We live in almost literally an archaeological site. There are 10-year-old applications, 20-year-old industrial systems, smart cards, embedded devices. I used to be very heavily involved in corporate training on the capital markets.

We said many times that the average tier one bank has over 40,000 legacy systems that keep those organizations operating. We are dealing with things not only internally but third parties. What do you do if your crypto agility stops someone else's product growth? Organizations need to literally classify these legacy systems, this archaeological site that we all operate in, into several categories. I think we need to first identify what systems can be upgraded, what systems can be, say, wrapped or isolated.

We need to be looking at maybe temporarily through gateways, protect them from segmentation and proxies and other compensating controls. Then some may be able to survive through the remainder of their useful life because the exposure is really low, and others will simply just have to be replaced. This is a dangerous category. We can't change it, so we're going to ignore it. We can't say that about any of these systems. That's not a migration strategy. One of the things I would encourage organizations to do very, very early is identifying your cryptographic dead ends.

These are systems which would be extremely expensive or operationally disruptive or literally impossible to migrate. We talk about systems that are software-based.

Well, what do you do if your algorithmic encryption is hardware-based? It's not easy to get to wherever that hardware is. If you think of satellites that have been up in outer space that manage a lot of our communications and probably everything that we're doing here on this webinar, you can't just go up there and replace that board with an updated encryption system. I think the hardest migration problem isn't necessarily your most important application. Absolutely true.

And again, just to quickly reiterate, there is no single answer right or wrong to a question that goes something like, and I've heard it so many times, so if I migrate from the classical cryptography to the post-quantum one, will it affect my business processes or will it be slower or faster or complex or simpler? There is no answer to that. There are thousands of answers and they are very interdependent and interconnected because the repercussions of one system can go much further.

You replace the digital signature of an API endpoint and now somehow it's running too slow to fit into your SLA or it no longer keeps up with the financial transactions you need for stock exchange trading or something else. Or you introduce some kind of a model replacement, which fixes 99.9% of your specific issue, but that 0.01% ruins everything else because you cannot retire it. How do you build, how do you work around that? And this is really something which there is no single simple answer. It goes again back to the very beginning of our presentation.

Inventory, dependency mapping, and risk assessment. Everybody has to do it for themselves. I guess the only question is how to do it. One of the things you brought up very early was what does regulation or procurement or leadership have to say about these things? When we start to think about it from that perspective, we've kind of spent the last 15, 20 minutes talking about the engineering problems. But really, the engineering problems are maybe even the easiest part of this equation. We are having regulations come down that are giving us deadlines. How are we doing that?

That means that our procurement systems have to be out there. Those procurement systems have to basically understand what is underway, what they need to acquire, what is going to be supported, what is the useful life. That allows for procurement almost to become very, very powerful in terms of the solutions.

And, of course, then the other aspect of it is the leadership play. How do we go about developing the leaders to be able to take that step, recognizing that, A, there's a cost to it that we have to pay for? The second thing is there will be a time delay. It's a delay in implementation. And that implementation might be exactly as what you just pointed out, and that is, does my SLA now – can I achieve my SLA due to the bigger or the slower response due to this change in encryption?

It's almost as if we need to be asking ourselves – we ask ourselves and we ask our suppliers, are we quantum safe? That's almost meaningless.

Really, our question should be is, what standards do we have to support? And if you're a multinational organization, you have different standards that you have to adhere to depending on where the business is operating currently. We have to have a very fine and defined migration roadmap. We need to have cryptographic components that can be upgraded without replacing the product.

I mean, there's a million questions that we go through, but you're absolutely right. It's not just the engineering part. It's the regulation, it's the procurement, and it's the leadership. And if we start with those three at the top, the engineering problems will become easier to solve.

And again, on top of that, you always have to remember that you do not exist as a business. You do not exist in a vacuum, in isolation. A lot of your systems depend on the other end being able to support those standards as well. You cannot put a quantum safe pure PQC TLS certificate on your website because there are so many clients out there which just don't know what it is. They won't be able to open your website, for example. And this is just a single small primitive example. There are so many other issues. Hardware security tokens, how do you update those?

Identity providers and single sign-on standards like SAML, for example, how do you upgrade those? How do you federate all those changes across industries and geographies and countries and whatnot?

Yes, regulation helps, I guess, but it's still definitely not a walk in the park. Well, we know one thing about regulation, and that is that it usually follows innovation.

So, unfortunately, sometimes we can take a step forward with an innovative solution that regulators come in and change underneath this. That's why it's so important for organizations to spend the time to figure out not only what they need to be doing, but how do they need to be doing it to continue their operations. Because as you said, we don't live in a vacuum. We actually have to operate, still do all of our business while we do this migration. And the migration itself is never going to be easy.

I mean, if there's individuals out there who think that the migration roadmap is smooth, I would say, be prepared for a very rocky road and probably completely uphill. Right. And a lot of interesting surprises on the way. Right.

So, but still, we are limited. You just said regulations. They are there. There are some roadmaps and provisionally deadlines. How do we figure out our plans around those deadlines? You're right.

I mean, the big question from this takeaway that viewers and listeners should take is that the question really isn't, when will quantum computers break cryptography? The better question is, how long is it going to take your organization to change the cryptography when it has to?

Again, I mentioned the two clocks. Clocks is the first thing. When does quantum computers break cryptography? The second clock is, how long is it going to take for you to update your systems?

You know, any organization that understands its own clock is an organization that can act before urgency becomes a crisis. And really, the argument that we're making here for everyone is that you can either start doing things now or yesterday, ideally today, if you can't. But if you're not trying to do something now, which is when it's just an urgent issue, you're going to then have to be dealing with it when it's a crisis issue. So we're trying to make sure that that doesn't happen.

I guess one interesting question a lot of companies would probably have, at least I would, if I were a big company. Can I actually delegate this to somebody?

Like, if I don't want to run my own data center, I can go cloud native. Can I go somehow cryptography native and delegate it to somebody else? Are there any promises at least out there to ease your PQC journey? I would say yes, of course. There's always sales and marketing out there that is going to be saying that. That doesn't remove the liability for an organization, simply because you go out and find a cloud provider, as an example, who says that they can deliver you a turnkey cryptographic safe environment to operate your business.

The first thing is that there is no on-off switch to shut off the old systems and immediately begin running a new system. That's not going to happen. And the liability is this. If the third party fails to do it right, your organization is still liable for what the risk is. Simple things can actually then become cascading. Can it be pushed off? Possibly. Is that a best course of action? Probably not. Is there a way that you could have a roadmap for a 10-year type of migration to that type of a solution? Sure. That's always a possibility.

We have some of the best people in the world thinking of solutions that just seem unimaginable previously. So, yeah, absolutely. I think that there is a way to do that, but do I think that it's a prudent one? Probably not.

I guess, as we can see, more than one party of experts on different continents and different industries and whatnot, they are actually on our side. They work hard for years to make this process as hopefully safe and smooth as possible.

So, we are not lacking guidance and recommendations. If anything, we have too many of those. And I guess the most important question is whom do we trust more and whose guidance we should follow?

So, can we, because we have not a lot of time left, can we just go and offer, try to offer three things we, the group of speakers in this webinar, offer to our viewers? Where should they start?

Yeah, takeaways. Yeah, I would think that the three takeaways in my mind would be is that quantum is actually forcing us to recognize.

No, quantum didn't create the crypto agility problem. It just has exposed it. That's number one. The second is that trust is bigger than encryption.

So, what cryptography answers the question, why should I trust this? That is really going to be the most important thing. And then the third is this. This is an operational component, and that is that we must inventory, and that inventory must become intelligence. The goal isn't to document cryptography. It's to know what to change. Exactly. I cannot agree with that last statement, because again, a lot of people understand discovery as writing down a list. This would be the biggest mistake.

If you are making a list, at least make it a list of systems and processes and risks and not just individual keys and certificates and whatnot, because those disappear way too quickly. You have to understand the rules, how your enterprise worked with cryptography for those decades, and be prepared to change and bend those rules without too much breaking, right?

And yes, I think the second most important recommendation is you have to prioritize by risk and potential impact on your business continuity and processes and whatnot. Because, again, if your only finding is 2 million vulnerabilities, you won't even be able to finish reading it by 2035. There's nothing about actually fixing those issues. You have to identify where are your most dangerous edges and interfaces to your partners and what are the most regulated attack surfaces and whatnot, and start acting there, I guess.

And for some less important systems, you can probably build a temporary virtual thing around it, like a cryptography gateway, if you will, might work for some scenarios. I agree. So I hear we have some questions. Do we want to address those?

Well, we do have a few questions, and we have just five minutes left. So let's quickly go. The first one is, what are your recommendations regarding historically encrypted data in storage?

Well, that's the Harvest Now Decrypt Later. The problem is that a lot of us have been lured into safety that our data has been encrypted and, therefore, it is safe. The problem is that, again, I referenced this, that the Harvest Now Decrypt Later is looking back. There is a lot of IP that is out there for organizations. There is a lot of personal data that's out there that has a need for privacy.

But, you know, when you look at that, it is a backward-looking solution. I think that if we only look at that, I think that we're fooling ourselves, because identity and payments are the present and the future. It has to be a balanced approach. We can't just look at the past. That is at risk. There's nothing we can do about that at present. The only thing we can do is make sure that as we go forward, you know, if Q Day happens in 2030, we still have, you know, three and a half years of data to protect, so we need to be able to do something about that. All right.

Okay, next question. Is a combined post-quantum cryptography plus zero-knowledge proof architecture a recognized target? Can using a DKP as an abstraction layer provide organizations with cryptographic agility needed? What's your state? What's your position on that? Zero-knowledge proofs have proven to be a very interesting technology, and I say that it's a technology simply because its first implementation has been in blockchains probably over the past 10 years.

What we're seeing here is this, is that anytime we can take things that create a level of trust that is higher, mathematically higher, I think that that is a good thing to evaluate. Do I think that we have to include these things in all of our technology discussions? No. It may not be a solution that is relevant. Different algorithms are going to be useful for different operations, so those that can maybe take advantage of, you know, zero-knowledge proofs, that is a possible implementation aspect that we should consider. All right.

Okay, thanks. And the next question is, what would be two or three executive comments to a business board that are not convinced to start the crypto agility and quantum migration? So how do we persuade the non-techies? I would actually use the example that you used early on, and that is Y2K. We knew that Y2K was coming. There were a lot of people out there who were saying that this is at risk. We could find ourselves with operational dependencies, say, on power, water. These were all utility-based fears that were primarily there. That is the thing that I would try to say.

So if you have a board who is – or board members who are not really receptive to it, you need to point out that the risk is there. The second part of it is this, is that they have to come to a way to address this risk.

Now, the first and foremost thing is that someone within the organization has to be the accountable person who then reports to the board, the risk managers, to make sure that the organization can survive when QD happens. The worst-case scenario, in my opinion, is that an organization just ignores this completely, and then they will wake up one day and realize that their entire business is gone.

Yeah, true. Well, I guess this is exactly the right moment to wrap up our today's webinar, because I would love to have another hour of discussion, but unfortunately, we don't have it. We are already one minute over time. So it was a pleasure talking to you, Bryant. Thank you very much for being with us. Thank you. And thank you to all the attendees live and those who will be watching this later. Hope to see you in our future webinars. Show the slides on the future webinars. We do have a lot on our website. Please feel free to visit kubinerco.com.

And of course, feel free to learn more about Bryant's organization as well. If you're looking for specific customer-targeted consulting services.

And again, thank you very much. See you in the future, and have a nice day. Thank you.