PANEL: Post-Quantum Identity: What to Change Before the Budget Cycle Ends

So this session is about what to change before the next budget cycle. So we're going to try to address some of those questions. I'm going to try to set the stage with a couple questions, but then in the last five minutes of the session, I would like to open the floor to the audience. So if you guys want to be engaging, and if you have any questions, that will be an opportunity to contribute to the conversation. Maybe just a brief round of introduction. Maybe we can start first with Dr. Michael.

Hi, I'm Mike Jones. I work on standards primarily. I'm an independent consultant. I've helped create things like OpenID Connect and the JSON Web Token, the FIDO2 and WebAuthn standards. And I have a math degree, but I don't understand the cryptography. And I have a degree in computer science. And what I do is write and speak for a living.

Hi, everyone. I'm Bertrand Carlier. I'm an identity consultant for 20 years. And I'm not a cryptographer as well. I'm not a mathematician, but I do trust those guys to say sound things. And I trust them that, yeah, the apocalypse is upon us and we have to act somehow.

Hi, my name is Brian Nielsen, and I'm the CEO of Quantum Core Institute. And the best way to describe what we do is we're a risk advisory focusing on quantum computing. So from that standpoint, that's my perspective.

I, too, am not a cryptographer. I'm not even a mathematician, but I am a risk manager. Thank you for the introductions.

You know, we've been talking about quantum threats for some time now. There was a lot of noise in the past couple years, and then AI came. It stole the stage. But there are a lot of organizations already trying to think about what to do when this becomes a reality. Q-day is not science fiction anymore. So from your perspective, what are the, let's say, the most urgent identity-related changes organizations should take into consideration? Maybe we can start first with Brian. Sure.

I mean, to me, the most important things that need to be changed is, again, it's primarily from a governance model. It's not a technology question. The very first things that we have to do is we have to inventory where our risk surface is. The second thing is that we really need to be thinking about how do we then create a prioritization of managing those risks? And for the most part, this is a governance model. Somebody has to be specifically assigned to this. This isn't just an IT migration issue. This is something that the risk advisor or risk manager has to be a part of.

It's a part that the board of directors in public companies have to be a part of. It is a part of everything within IT, the CISO, the CTO. Everyone needs to be aware of that, and there has to be responsibility managed within it. I would add that I agree first. It is a risk management perspective that we need to have on this and to prioritize. And to come back to your question, you mentioned identity-related priorities. We can talk about the harvest now, decrypt later threat, which is about data production, not really identity-related.

If we want to focus on identity because we are at EIC, and I think that's the theme of the – yeah, there's AI, of course, but identity is maybe the second theme here on the conference. I think specifically to PKI, we have to think about – sorry, specifically to identity, we have to think about PKI. PKI are the trust anchors and are going – you are delivering certificates to end users or to workloads, and that's something to think about. If you are in your budget cycle thinking about replacing a PKI, now is the time to include a PQC, a post-consumer safe close in your sourcing strategy.

And the second thing is you have to know what you have to protect. So, you definitely need to have a good map, a good cartography of your applications for data protection, but also for authentication. Authentication is at risk, like Michael just explained.

So, you will have also to take this into account. I will certainly agree that managing risk is the hard thing, and it requires a cross-disciplinary effort. Even though I'm a technologist, I will observe that the business realities may give us a better forcing function than the potential future post-quantum apocalypse, because there's already legislation in a lot of jurisdictions that if you're going to sell to the U.S. government, if you're going to be involved in a contract for a supplier to the U.S.

government, to parts of Europe, to other parts of the world, you have to follow the guidance on quantum migration and get there by the deadlines that the legislation and the recommendations have. So, we may not know when the first cryptographically relevant quantum computer is going to exist, but we do know when the legislative deadlines are already.

And that, at least like Y2K, gives us something concrete to target, and we will either achieve it or we won't be able to participate in those markets. And today, where do you think you see the main gaps in certificate lifecycle or in cryptographic agility? What do you think are the main issues?

Well, cryptographic agility is really defined as the ability to replace the encryption capacity within whatever hardware or software solution that you have. And, of course, that has the potential to break everything that you make.

So, from that standpoint, to me, the bigger issue is not when will this encryption failure occur. It's that our biggest problem is that organizations have inertia. They're unwilling to even recognize it. And I'm just going to take one second here to give a little story, and that is back in 2021, a lot of scientists were asked, what is the most important thing, or when do you think we will have, A, artificial intelligence, and, B, when do you think we'll have quantum computing?

Back in 2021, which is only five years ago, both projections by the leading authorities was that this was something that was going to be somewhere between 10 to 15 years away. We have seen what happened with AI in November, late November 2023, and now we're in a situation where we're encountering iterations, massive iterations and improvements that are happening so fast that we're sitting here from a year ago, not even talking about AI agents, to now where this conference is all about AI agents and the management of them. I truly believe that quantum is going to be essentially the same.

It's going to come upon us so quickly, and then we're going to be playing catch up. We won't even be able to run as fast as it's changing. I would add that I think we've seen things change a bit last year when, for instance, in the EU, the European Commission provided guidelines and timelines to do your inventory and your migration for critical assets and all the other assets. I think the change is awareness. In the head of many companies, they know that they have to update something by 2030 or 2035.

I don't think they understand and they realize that they have to update something else than data encryption. I really think that tokens architecture, the protocols like SAML, OpenID Connect are broken with a quantum computer, and SAML is probably going to be buried finally, but OIDC will have to be migrated. I don't think companies realize that they will have to migrate all the applications. They realize that they have to encrypt with quantum safe. I don't think they realize they have to update the protocols that underpin authentication.

Well, indeed, I had a slide saying, and you made the same point, you're going to have to inventory what you have and make an action plan and decide what to do with it. I'm not making this up, that if all this comes true, every piece of software that uses cryptography is going to have to be updated or replaced. That's not easy. It's not easy on several levels. I had that penultimate slide where I said we do cryptography, then we do standards using the cryptography, then we build software using the standards, and then we deploy the software. Each of these is increasingly hard, actually.

Again, the hardest thing is getting people to start to act in the first place because of the inertia factor that you pointed out. One of the things that we've been talking about is this hybrid approach. How realistic do you think is this hybrid cryptography as a near-term strategy, and does that add more complexity? It's no much harder than doing any algorithm migration.

Yes, the clever cryptographers, some of whom I know at the ITF, have to do combination algorithms, and standards have to be written about how to do the combinations for signatures and encryptions. In the end, that's just math and data structures. All cryptography is just math and data structures. There's engineering choices because some of the things are bigger, some of the things are slower, some of the things are faster.

So, there'll be these trade-offs, but I'm involved in standardizing some hybrid stuff. It's not hard. It's just normal standards work. The hard things are the human parts. With people arguing, well, we only want to do this, we only want to do that, we want to do these three things, we want to do these seven things, but that's the consensus process. That's part of standardization. Where I'm out of my depth is how you get vendors to update your software in time and how you have a deployment plan for that software, even should you be able to obtain it.

I'm going to be a little contrarian here, and I think that a hybrid strategy is just a migration strategy. It is not a security strategy. It's a half step to actually solving the real problem, but if that's what you can do, it's better than doing nothing at all. I would really say that it is also a security choice, like it was presented by the previous presenter. We don't have 40 years of experience of the quantum safe algorithm, so can we afford the risk to have those algorithms broken and not have a classic cryptography algorithm in place? I think hybrid is the safer choice.

Again, the threat model, not everyone is going to be targeted by nation state actors, things like this, so you have to do your risk analysis and look at the threat model. The other thing is sometimes you will not have a choice.

Germany, France are going to require hybrid cryptography. It's not so clear in the US now that there are different voices. For European companies, I think the choice is not theirs. It's going to be mandatory anyway. I'll actually disagree also. It is a security choice in that we don't know, for instance, whether MLDSA or ECDSA will be broken first. Because we don't know that and just ignore the possibility of quantum computers, even without that, we don't know which of those is going to be broken first.

So if you use both of them in a secure combination, at least the time that your algorithm is broken is the later of the two. You don't know which is first. Before I open the floor to the audience, one more question. What should identity leaders be asking vendors and service providers regarding PQC readiness? What are the right questions? Implement the standards we already have now. Put it in your production releases. Roadmaps. You cannot build your own roadmap if you don't have the roadmap of your suppliers. That's true. That's definitely something you can ask right now.

Maybe they don't have the answer, but they will try to find the answer, and they will ask their own suppliers, and that's how we're going to be able to build the timeline for every company, I think. Really, the thing that I would say is this, is that I don't want to see organizations treat their vendors as just a checklist of verification.

I want the ability to have these vendors actually have to prove through some type of audit, whether it's their architecture audit, their evidence-based audit, that they actually have deployed some post-quantum algorithm solution so that it's not going to be something that is an unknown. Thank you for the insights. Now I'd like to open the floor. Any questions from the audience?

Yes, give me a second. Hi, thanks for the panel and the explanations.

Very good, and a good update also from the previous presentation. I would like to comment something additional. My impression is that you are very focused on algorithm or vendors, but I think that maybe 30% of systems in companies will be legacy systems, custom developments, custom integrations, and this is not sorted out by vendors. So I think that that will be probably the hardest part for the migration, not the vendors. They are late maybe with the roadmaps, etc. I agree with that, but that is a part that maybe are more concerned or more concerning for companies.

And also beyond that is the architecture. It may be the opportunity to think about new architectures that consider not just the algorithms, but how I manage the new keys, how I protect the keys. Passwords are no longer valid under the post-quantum. They need to be very long to keep enough entropy. So I would like you to comment on these maybe broad topics, but I think that are complementary to your presentation. I think we have to be smart and clever for those niche or legacy that may be half of your estate.

For instance, I think we're seeing experimentation of having encapsulation, for instance, of network flows. So components that are not datable, that will not be datable and use the correct algorithm, could be encapsulated using proxies doing quantum safe network. I liked also the example that Michael, you presented, which is going back to symmetric cryptography for some things like TOTP is quantum safe. Same for firmware signature on objects.

Currently, Automotive Maker, for instance, they do signature of the many firmwares that are updated in a car. It can be 40 or more different dates that a car receives. And if you cannot sign this with a quantum safe algorithm, maybe you have to switch back to symmetric signature in HMAC. And there may be generations of objects, cars, things like this, that will have to resort to not optimal, but clever way to be a quantum safe. That's what we see currently. Engineers are trying hard to do without the target algorithm because they don't have the target hardware yet.

It's not available yet to be produced. I'm just going to deal with your question in a slightly different way. And that is, is that, so I come again from the capital markets background. And one of the things that's most interesting about capital markets is, is almost every tier one investment bank in the world has somewhere around 40,000 legacy system that they're supporting.

These are, some systems are written in cobalt. Now, some of you may not have ever heard that word before, but they're trying to support these things. There has been a, almost a generational lack of not wanting to upgrade systems that we're all highly dependent upon.

And so, you know, part of the question that you're, we're addressing here is this, is when we think of trying to solve these encryption problems, we're also going to have to be dealing, and it's going to force our hand on this. It's going to force our hand to say, all these legacy systems are also going to have to be updated. So this or replaced, well, that's what they will be done is they'll be replaced.

But it, this is a monumental task that, you know, organizations have been ignoring for decades. Not, this isn't something that just has emerged in the last, you know, two years or three years. This is a multi-decade ignoring of a problem. And I think we already had such kind of migration when we, when we had to get rid of MD5 or SHA-1. And does anyone can lift a hand if they don't have any SHA-1 anymore in their, in the information system? I'm not sure we can, you don't have any? Okay. But your very reasons. But your very reasons. Exactly. Yeah. Sure. I believe you. All right.

Well, thank you very much for your time. It's time for the coffee break.

So please, a round of applause.