Future-Proofing Authentication in a Post-Quantum World

Welcome to the KuppingerCole Analyst Chat. I'm your host. My name is Matthias Reinwarth. I'm an analyst and advisor with KuppingerCole Analysts. We are in the series of episodes that we internally and externally call the Road to EIC. So we are looking at topics that are relevant as key topics for the upcoming EIC conference in Berlin in May. And one topic that we covered already last year, I did this with Alexei, our colleague. And today we want to look at what has changed, has something changed and what have we learned in the meantime.

We want to look at post-quantum identity or more specifically at future-proofing authentication. So first of all, let me introduce my colleague, a recent guest, Jonathan Care.

Hi, Jonathan. Hi, Matthias. Thank you so much for having me again. It's a pleasure. Great to have you, Jonathan. And we want to look at the topic in a different way. We want to look at it like we do in a good TV series when there's a new season. We look at what happened in the meantime and what happened in the last episode. We want to look at the quantum clock that is ticking. We have new computers that are looming around the corner and they will break encryption. But is this the real important part that they are breaking encryption?

Or why are we talking about that when Copenhagen Coal is so much an identity company? Why, of course, also a cybersecurity company, but we're looking at it from the identity perspective. So why is identity the quantum bullseye?

Well, I think there's a couple of things here. First of all, identity assertions. So I am JC at copenhagencoal.com. So my email address is an assertion of my digital identity. All of these are secured and protected by cryptographic controls. So in the case of Copenhagen Coal, we had passwords. We've now moved to passkeys because as Matthias says, we're a forward-looking identity company. But passkeys and passwords are both protected by cryptography. And the reason that we can establish trust is based on public cryptography and Kerberos and all these other very important crypto protocols.

And I think, so if quantum or when quantum breaks encryption, then lots of things will happen. And lots of people say, well, oh goodness, there's going to be governments who have been storing encrypted messages for decades are now going to be able to decrypt everything.

And yes, that is a potential concern for many people. It's certainly going to erode the privacy boundary, which is something obviously Copenhagen Coal is very interested in. And I think the identity piece is very simple to say. Authentication protocols depend on cryptography. Identity is the new perimeter. We say this, and when you come to EIC and we meet in person, we'll probably say that to each other. What does it mean? It means that in a zero trust architecture, 90% or even every access decision hinges on cryptographic identity verification.

And if that is breakable, then bye-bye zero trust. And I talked about Copenhagen Coal as a looking identity company, which we are. And like many organizations, like many banks, like Apple, like many organizations, we have moved away from passwords towards these cryptographic authentication methods.

Parsky's, Fido2, and Specificate-based Auth. And I think while I was in, many decades ago, when I worked at Sun Microsystems, a friend and colleague of mine developed an automated password cracker, which was basically exploiting some of the vulnerabilities in the Unix crypto algorithm. No doubt that the crypto underneath needs replacing. So we have a problem in that we've moved away from passwords, we still obviously rely on cryptographic storage, towards cryptographic authentication conversations.

And I'll say Parsky's, Fido2, Certificate-based Authentication, being just three that come to mind. We've replaced the weakest link, that being passwords. And I've said this for years, I know Matthias and our friend and colleague Martin have said, passwords are the weakest link for many, many years. And we replaced it with a mathematically beautiful, robust cryptographic architecture. Unfortunately, quantum means that that mathematics itself is under threat.

So this is a problem that as security architects, as software designers, as AI operations, or security operations, we've not faced this where actually the mathematics is under threat. But if we assume that, and now I'm really playing a bit, you have a layman or the devil's advocate, let's say in five years, there's quantum computing around and in five and a half years, every cryptographic mechanism that actually underpins authentication is broken. So we need to take care, say in four and a half years. Why is that a wrong assumption? So what am I missing?

Is it just the authentication or is there more? Well, as we've seen with many scenarios, we're not very good as humans about thinking about something we need to take care of in four and a half years. As evidence for myself, I've had a diet issue that I need to address, which is going to be a problem in four and a half years. So we're not good at that as humans. We focus on the immediate and we focus on the big things. So it's very difficult to focus a mind unless, of course, you are a specialist in this area. But let's turn it around and let's look at those facts I mentioned.

I mentioned nation state adversaries, and you think, well, why does a nation state care about me? I don't know why nation state care about you. But it is entirely possible that your messaging, it is entirely possible that your banking traffic is entirely possible, that whatever you may be doing, which is currently protected by cryptography, is of interest, even if it's just building up that picture of communications that ELINT companies or ELINT organizations like to do.

So if they're capturing authentication handshakes, certificate exchanges, and federated identity assertions, which right now are robust, they won't be. And it's interesting that I mentioned banking, and of course, that's the falling siren call that many people use. But the Federal Reserve in the US published a paper in September specifically on this risk, which is HMDL, harvest now, decrypt later. So we're no longer in theoretical territory. This is a real issue.

And I say, as security architects, we do need to be cognizant of what's going to happen in four and a half years' time. And let me, again, hone in a little on the specific risk to identity because people say, well, I don't care if some government reads my emails. Let me give you a identity-specific scenario. A captured authentication session could be replayed, could be analyzed to extract long-lived credentials, be analyzed to extract session keys or identity federation secrets.

Now, a friend of mine who's security managing one of the big companies that provide cloud services says that the thing that really gets them going is when they hear about an endpoint being lost. Because long-lived credentials, session keys are all up for grabs on that endpoint. So scale that not just from the, oh no, I've lost my laptop, which is occasional, to everybody has lost long-lived credentials, session keys, and identity federation secrets.

You then have a problem with all of the cloud services you access, all of the cloud services that underpin the cloud services that you access, and so on, and so on, and so on, are then up for grabs. And we know we've talked about transitive trust for a long time.

Well, this is going to be the biggest transitive trust problem we've seen with the target group being everybody. You mentioned four and a half years.

And yes, I think estimates have said it's between three and 10 years, but the identity data being harvested today has value for decades. So CISOs, the question for you is not when will quantum computers break my authentication? It's what identity data is being captured right now, which is up for decryption later. Right. So there is no chance to wait until then.

We should have started last year, and we should have maybe started even earlier to apply this, what people call crypto agility, to say, okay, let's exchange the algorithms with ones that are stable against this expected quantum computing data encryption part. So how to do this? What has maybe changed in the meantime since we talked about that last time? I'm a great friend of standards, of interoperability, of testing, of testing scenarios, interoperability testing. Is there something that is going on that we can build upon to start right now?

Well, there are some standards, and I was going to make a joke about I'm not friends with standards. I just say that so they'll buy me a beer. But there are standards that are there that help us, and the three FIPS standards that come to mind, FIPS 203, which is known as MLChem, which is module lattice key encapsulation, and that replaces the key exchange with protected cryptographic objects, something I worked on a while back when I was doing stuff for UK government.

The other one that's of interest is FIPS 204, and that's, again, module lattice digital signatures, and this replaces and hardens RSA, ECVSA signatures. So the good old RSA, which never has gone away, and also the encrypted, sorry, the elliptic curve cryptography digital signatures are able to be replaced by that. The final one of the trio is FIPS 205, which is SLH DSA, and this is exciting because this is stateless hash-based digital signatures, and that gives us, again, a backup to FIPS 204, but also some diversity. We have choices.

I'm particularly interested in that because the idea of a stateless digital signature means we're no longer relying on potentially weak exchanges prior to the digital signature exchange. So there are some good news. We have these primitives. We have these, and I'm trying to think, for those of you who are keen chefs, we have some really great ingredients coming into our kitchen, but the recipe, the identity protocols, have not been fully updated, and particular questions that come to mind. How do you issue post-quantum certificates at scale?

When it's everybody in your 20,000 person organization, when it's everybody in your 200,000 telecoms organization, how do you issue certificates at scale? What happens, furthermore, to PKI hierarchies? I share a joke with a friend of mine who now ended up in one of the vendors, and I talk to Dave, and I say, yes, Dave, 2026 is going to be the year of PKI, and we've made that joke now since 2015, so we're still waiting. But what happens to PKI hierarchies when root CAs need to transition? The basis of trust, so they say, hey, we're going to change, and you need to change with us.

There's going to be an awful lot of people who are scrambling at that point. The idea of hybrid certificates, so a homogenization, a mix of classical and post-quantum certificates, is still being standardized at IETF.

Now, the good news is, we are expecting something in early 2026. The bad news is, it's now early 2026.

And so, I guess the thing I would say is that we have the building blocks, we have the ingredients. What we don't have is the architectural blueprint for rebuilding identity infrastructure on top of those building blocks. Right. This still sounds a bit scary, and you've talked about the large-scale infrastructure, so really these large PKI trees that rely on root certificates, and changing this might be an issue. But if we get closer to our daily life, we are doing authentication with, I don't know, OIDC, OAuth, SAML, FIDO pass keys.

What is the impact of what we are just talking about on these technologies? And can this be solved easier, or are we still waiting for the same building blocks that you just mentioned?

So, yeah, let's start to drill down. And I think the question there, if I understood it correctly, is what's going to happen to the stuff we use in our daily lives, specific authentication technologies? I mentioned pass keys, FIDO2. I also mentioned PKI, but then also SAML, OIDC. All of that is, of course, again, very important for client services.

So, just looking at that, again, there's good news. FIDO Alliance has updated specs to support PQ signature algorithms.

So, once again, I think the FIDO folks are doing the right thing. The analysis I've seen says that pass keys and FIDO2 have quietly become quantum safe. I love that, because if it's quiet, there's no fuss, no must, it's just done. On the other hand, the entire ecosystem, authenticators, blind parties, and platforms need firmware and software updates. The firmware in your phone that protects that trusted enclave needs an update. UBQ are already demoing PQ-ready security keys. And for those of us who have moved to pass keys, there's considerable evidence to say that we've made good choices.

They are the best positioned authentication technology for the PQ transition, because they're already based on publicly crypto, and that upgrade path is clean. It is quiet, no must, no fuss. PKI and these certificates, they become important for much in our daily lives, including our directory, active directory structures, including much of our authentication, including obviously TLS is based on PKI. And PKI is deeply embedded almost everywhere in enterprise identity, including the growing field of non-human identities.

So if you think you're going to have a problem, just wait until you see what your fridge does. Certificate sizes are going to increase significantly with PQ algorithms. If we want crypto agility, we don't get it for free. We're going to have a larger data load. So for example, an MLDSA signature is 2.4 kilobytes versus 72 bytes for ECDSA. And when you're thinking about what you can get on a smart chip, something that you can embed in a SIM card or whatever, that becomes significant.

The other side, of course, is that we are dealing with these larger certificates, and therefore the handshakes will be slower because the mathematics is more cumbersome. It can take more bandwidth.

So again, TLS-based transactions between the payment terminal in your store and the bank will take more bandwidth. And of course, when I think about constrained IoT devices like payment terminals, and I frivolously just said the fridge, my car is an IoT device, and my CPAP machine is an IoT device.

Arguably, my mother's pacemaker is an IoT device. All of these constrained IoT devices, which not only include medical, not only include personal and consumer, but also some industrial devices as well.

So again, pump controllers that are in some isolated place in the Swiss Alps, for example, are all going to be affected by this. And route CAs, it's a multi-year planning exercise. We've never had to think about this or do this before. And so this is going to be fraught with a lot of work and a delicate thing to achieve. I think our approach, Matthias, when we talked about this, is that this idea of hybrid certificates, issuing certs with both classical and PQ signatures is the way to go in transaction. So we've got a fallback method.

When I look further down, when I mentioned federation protocols, so SAML and OIDC, and this is everything in cloud. Everything, but everything is based on SAML, OIDC, and of course, OAuth token signing. So SAML assertions are XML signed, so we need to upgrade the signature of them to include PQ. OAuth token signing, JWTs, and I was talking to Matthias just before we started talking and saying, well, I need to make sure that I'm using a proper API key, not just grabbing a JWT for a little AI project I'm running because I don't really want the LLM to get mad at me.

But again, we're going to need PQ-safe algorithms in Jose specifications and the federation chain problem. We are as vulnerable as the weakest link. So if any link in a federated identity chain uses vulnerable crypto, the whole chain is compromised. And finally, something which is very visible to CISO security architects and desktop support people, Enterprise IAM. Active Directory that uses certificates and Microsoft fortunately have published a PQ roadmap, which looks good.

However, there's going to be a lot of migration activity required. Smart card authentication. I mentioned the ICC chips that you find in ICAO smart travel documents like our passports now. Any smart card is going to need a physical token refresh. And the refresh cycle for that is three to five years. So you as an organization need to plan now for anything that you're using smart card authentication. And oftentimes it can be treasury services. It can be high trust healthcare services, the things that you really don't and can't afford to have break.

I mentioned frivolously as we went past, I said, what about machine identity or NHI? What about API keys? What about service accounts? What about MTLS?

I mean, right now, I mean, actually, one of the things about NHI that we're all saying is, hey, we're just overlooking the problem of service accounts. Well, watch out because here it comes with teeth. These things are often overlooked, have a massive scale challenge waiting to bite us. The scariness is not getting better while we're talking. So we will talk about that at EIC. This is a road to EIC podcast episode. So I skipped the vendor part, but I like the way that you, Jonathan, in person are writing advice for CISOs. And maybe we can close down that episode with a clear roadmap for CISOs.

What should they do? And I think this is some, as you said, three to five years, 10 years, five and a half years. This is something where they should start now, but such a roadmap should be much bigger. If you can lay out that, and then all of those who are listening can just jot down some more. I strongly encourage you, if you're listening to this, EIC is where you need to be. We're all in Berlin in May, and you will find discussion of this that you literally won't get anywhere else. And I worked in other analyst companies.

I can tell you the people I'm working with are significantly smart and are thinking about this in ways that even astonishes me. But let's talk about the CISO. And this again, we'll be talking about this at EIC. There's a four-step plan really. Phase one now is discovery. Where is this being used in your stack? You need to map the certificate authorities, the key lengths, algorithm dependencies. You need to identify which systems are crypto agile and which ones are crypto rigid. So what we're going to find when we do this discovery phase is that we don't know where all certificates are.

And we went through this with several different vulnerability disclosures that we didn't know where things were. We're going to find certificates buried inside a printer. We're going to find it inside a vendor managed system that we've never touched, or we don't even know how to issue a change for. We're going to have to prioritize then. What are the high value, long lived identity assets that we need to focus on first? What are we going to do about our root CA certificates, which have 15 to 25 year lifespans?

Again, this is organizational identity. What do we do about VPN and NTLS certificates, where we have people accessing sensitive environments?

So again, you may have developers who are trying to get into a sensitive environment. They need a trusted, protected right to access it. Speaking of developers, we're going to have to prioritize code signing. If you are a software company, and I quote JP Morgan, who said, we're a software company that happens to do banking. So we're all software companies, and code signing is going to be important. Think about all of the music creative.

Again, code signing becomes important there. All the financial transactions, code sign becomes important there. Everything we touch will need code signing certificate looked at, because the integrity of our supply chain is important. Data with long confidentiality requirements, and I briefly mentioned healthcare, briefly mentioned financial, but also government as well. Things with decades long confidentiality requirements will also need to be top priority. The third phase is to test this idea of hybrid.

So deploying hybrid key exchange in test environments, measuring the performance in compact authentication flows, and testing operability with identity federation partners. ISACA has released a 12 month playbook, and it has practical quarterly milestones for post quantum readiness. Phase four is into 2027 and beyond, we start the migration. We transition production identity infrastructure. We update CA hierarchies and reissue certificates, and we ensure backward compatibility during this code distance period. Right.

So there is a plan, and this is as you laid out, it's really something that you can really start right now by cleaning up the basement and looking what you have, and we need to get into the migration phase in two years from now, one year from now. So there is a plan, but it sounds like a lot of work, and a lot of the damage is already done. When you say the lost laptop could be subject to decryption anyways, because it's too late for those. The sooner we start, the smaller the blast radius, because we make sure that the next lost laptop may be encrypted in a secure manner.

As I said, this is an interesting topic, and we are already running a bit longer, but I don't want to end before us having some key takeaways from you. What would be your key takeaways, apart from the phase plan that you just mentioned? What should be something that we have under our bedroom pillow to keep in mind when it comes to crypto agility, when it comes to post-quantum? Personally, I keep a sandwich under the pillow just in case I get hungry in the night.

But in all seriousness, the key takeaways and the things that all of us from Cup and Kikol will be talking and asking people about there is, what are you going to do about this uniquely vulnerable identity layer? It's not just about data. It's about the integrity of every authentication decision.

Again, what are you doing with discovery? Because you can't protect what you can't see.

As I said, crypto inventory is step one. The real goal here, and again, we'll be talking about this, as I keep saying in EIC extensively, the real goal is crypto agility. The ability to swap algorithms without rebuilding infrastructure. If you are using passkeys in FIDO2, congratulations, you're ahead of the curve. You've got that tailwind to move you towards passwordless, which will help. The final thing, and as I say, the window for planning is now, which is why we're going to be talking about this a lot in Berlin.

Migration is going to take three to five years for large enterprises, and the threat is already active by HMDL, I mentioned before. Well, these are great takeaways. As you said, we will talk about that at EIC, but I don't want to make it too much the commercial break part of this section, but we also do advisories. We are up here to support with helping you in making the first steps towards crypto agility. If you have questions, reach out to Jonathan, to me, to Kuping and Kohl. That's where we can help you.

Otherwise, follow this podcast, follow our blog posts, follow our research. There is a lot to digest, and we will meet you at EIC in Berlin. If you have any questions for this episode, please leave your comments below this episode on YouTube in the comment section. It is monitored. We are looking at that, and we will reply. If you're listening on, I don't know, on Apple iTunes or Google Podcasts or whatever, just drop us a mail. You have already mentioned your mail address. It's JC at Kuping and Kohl. It's MR at Kuping and Kohl, and just reach out to us.

We are really happy to get your feedback. Oh, and on LinkedIn, and social media will also be involved because we need to authenticate there as well.

Thank you, Jonathan, for being my guest today. That was a great episode, and it showed what happened and what did not happen in the meantime. The quanto calypso is not there yet, but we have a bit more time to look at it. We still do not know when it will happen, but we do know that we need to prepare right now, as you've mentioned. The planning window is now.

Thank you, Jonathan. I'm looking forward to having you soon again.

Thank you, Matthias. If I can leave a final word, the biggest risk isn't the quantum computer. It's the 10-year certificate you issued last week using RSA 2048.

Yes, that's true. That will be a long-term mine in your garden that will be around for some time.

Thank you, Jonathan. I'm looking forward to having you soon and latest seeing you in Berlin.

Thank you, Matthias.