As a professor of computer science and engineering at New York University, Justin Cappos has built software and systems designed to handle the worst situations imaginable: exposed developer keys, repository attacks, and compromised X.509 certificates, to name a few. In 2010, he designed The Update Framework (TUF) to support software supply chain security and contain failures, so a single compromised component can’t be chained to create a working exploit.
Cappos has spent a lot of time thinking about what teams get wrong when it comes to cybersecurity. “A lot of organizations build security solutions that are fair-weather solutions,” he says. “It’s like having a convertible that doesn’t have a roof.” On a nice day, it works perfectly – but when a storm rolls in, it can do a lot of damage.
Quantum hacks are one of the storms that Cappos says organizations should prepare for now. In this condensed Q&A, he explains what teams underestimate about the post-quantum transition, why the worst-case scenario would look worse than Y2K, and how to start preparing now for a post-quantum world.
People really need to wake up and say, we do need to worry about the fact it rains sometimes.
Justin Cappos, Professor of Computer Science and Engineering at NYUPeople are often surprisingly bad at thinking about what might go wrong and how to deal with those situations. And so one of the big problems that comes up whenever you do any kind of transition in cryptography is supporting clients that have not made the transition alongside clients that have made the transition from an operational standpoint.
It’s a little bit like, if you’ve never been in an earthquake, you might think that earthquakes don’t exist. Same with tornadoes or hurricanes — there are some things that people sort of underestimate. They’re low-frequency, but they’re problematic events. Transitions often create situations where you might have some developers that are signing things with outdated algorithms, while some are using post-quantum crypto algorithms. And how does that all work together? It becomes a fairly complicated scenario.
I think it’s fine for them to think about replacement, but I think it’s in some ways better for them to think about how they are going to support the changing of cryptographic algorithms. And that’s actually something in the TUF system that I built. It’s one of the things that we thought very, very hard about. It’s all the failure cases and all the cases where you’re transitioning and how you do things and how you support things together well in an operational environment.
You fundamentally need to take the time to do that well, because if you don’t, then you end up in a situation where it’s like, oh, what are we going to do? Just thinking “On this date, we’re just going to tell everybody they have to switch,” or “We’re gonna have an old server that’s around for some amount of time, and then we’re just gonna eventually shut it off and hope for the best,” those kinds of things have not worked particularly well in practice. I think the sooner people build a smart transition mechanism in, the better.
And the problem with post-quantum crypto is that now it seems like there’s quite a plausible end date for when this needs to exist. For example, France won’t certify products that don’t have post-quantum algorithms starting in 2027. Organizations that are behind the curve are now in a really difficult situation, because they need to not only use a new algorithm they haven’t bothered to get any experience with, but they also need to figure out how to do that transition smoothly. And so, this has the potential to be problematic. But we’ll see what really happens.
If we imagine a world where on January 1st, 2027 every hacker in the world gets access to a quantum computation that can break all the classical algorithms, then there would be absolute pandemonium. This would be very, very, very bad. Like all of the projections people had about what would happen in Y2K might actually come true, in that scenario, and then some.
The more realistic scenario is, a few governments have this in 2028 or 2029 and possibly even have it now, or at least are getting it very soon. And then some big companies and researchers show it’s possible to get this. And then pretty much all of the major countries that want to invest in this have this as some sort of spying capability and also, some nasty offensive weapon technology for all of the IoT devices and things that are going to be hard to transition.
But hopefully, everyone will realize that they can be hit by this as well. We all need to get better at what we’re doing, and we need to fix this, and do this right. And unfortunately, if people are just starting now, they’re way, way, way, way, way behind the curve.
You could have things like old hardware, tokens, and things that you might need to update. This could be an actual burden, but usually it’s a software change. The places where this becomes most difficult or problematic are often situations where there’s a constrained device, like a device that has limited memory, or limited processing power, or limited battery, or something like that.
It’s not just a matter of setting up a Zoom call where the connection went from taking 200 milliseconds to 280 milliseconds or something like that. It’s now maybe a matter of, in order to make this really work well in the first place, they had accelerators on board to do a few very, very basic operations, and now they don’t have the ability to have hardware accelerators for the post-quantum crypto things. The keys are much larger, and the information they have to store is much larger. If you’re worried about something like a seatbelt tensioner in a car, which has a tiny embedded microcontroller inside of it that has kilobytes of memory and storage on it, it really makes a big difference, and you really might not be able to transition in a clean way.
So those are the sorts of environments where there’s a real fear that the path to updating is not clear, and perhaps makes a device that was operational no longer be able to effectively be operational.
If you just try to use the web to do authentication authorization, you end up in a situation where you have a web server that once it gets attacked, the attacker can compromise all your users. So Web PKI is fundamentally not enough for just delivering updates and software securely. This is certainly not true in 2026, and it wasn’t true in even 2016, but the writing is 100% on the wall about this now.
Actually, 6 years ago, our TUF system, which does secure, compromise-resilient delivery of updates, was the first system we’re aware of to do a wide-scale deployment of post-quantum crypto. We did the early SPHINCS algorithm before it was even SPHINCS+, before it was a standard under NIST and that kind of operational experience was very helpful to us to understand the need for crypto agility, the need for better ability to transition and do things in a secure manner.
TUF is a way of distributing software where it makes the assumption that everything that could possibly go wrong might go wrong and tries to minimize the damage from an attacker.
So it assumes that, for example, the attacker is going to break into your repository and have control of it. It assumes that the key that one of your developers uses to sign the updates is going to be compromised, as well as other things like your TLS or your X.509 certificates. Because these things have happened hundreds and hundreds of times, even to major organizations. And because of this, TUF has this property where it fails gracefully. It’s kind of like the crumple zones in a car. If you get into an auto accident, you don’t have to die, the car can be designed in a way that it minimizes the damage to you. And yes, if a meteor drops from the sky the size of the moon and it hits your car, you’re gonna die.
But the sorts of scenarios that have to happen to cause catastrophic damage are like, Ocean’s Eleven, Mission Impossible-style scenarios, in many cases. And despite the fact TUF’s been deployed over 16, 17 years now across lots of organizations, there’s no attack that we’re aware of that anyone has done that’s been successful in causing any damage to a TUF repository.
That’s the philosophy that we think people need to build into their security systems, especially in the Mythos/Fable age.
In general, if you are in a X.509 world for things that are web-facing, and for things like service-to-service, short-term communications, it makes a ton of sense. You want to have a model where those are scoped to have the minimal amount of trust that they need and where between services you have things like mutual TLS.
And ideally, you also want to be doing some type of certificate rotation over time so that if something does get leaked or compromised, it gives an attacker a very limited window to go and use this internally. It’s very common to have something like a 10-minute window of validity on these types of certificates. Doing that type of stuff and that sort of setup, if you’re using systems like SPIFFE/SPIRE that provide this in an effective way, it helps put you in a good situation where a provider can help you figure out how to do the post-quantum crypto. Have them help you with the rest of the setup, so that you can focus on things that you want to do.
For the most part, people just want to treat all of this as a library they use. They don’t want to spend their life trying to think about these problems. And so using off-the-shelf solutions that do 90% of the work for you is absolutely what organizations should do. They should not try to roll their own unless they are a security organization that’s providing this as a service to others, and they know what they’re doing.
A very common mistake I see in systems is someone that says, oh, well, we have a way of pushing out updates, and we just put them on our server, and if something goes wrong, we’ll just push out a new update and replace the key.
Well, if something goes wrong, then the attacker could have pushed out an update and put their key in place instead. And then what are you going to do? And they have no answer for that. So you really need to think carefully about all of the things that an intelligent and motivated adversary could do to negatively harm your security if they get different actions. And don’t just assume things like, I’m going to be able to regain immediate control of my infrastructure, or I’m going to be able to do X or Y, or that everybody’s going to be able to go and fix things.
There are a lot of people, a lot of organizations that build security solutions that are fair-weather solutions. It’s like having a convertible that doesn’t have a roof. And that’s a really nice car to have when it’s sunny. But if it rains, it’s not a good time and that’s not what you want.
People really need to wake up and say, we do need to worry about the fact it rains sometimes. We’re in the Mythos, Fable, etc. era here. All the vulnerabilities and problems and things that we’re seeing are becoming easier and easier for people to find and exploit. And maybe in the next 18 months or so, we’re actually going to be able to get ahead of a lot of these, but maybe we’re not. Maybe this is just going to be ongoing, where increasingly harder-to-find bugs are going to be found by more and more models, and models will increasingly be able to chain exploits together. So I think if you’re putting all your eggs in one basket you’re definitely doing it wrong in 2026.
This Q&A is condensed and lightly edited from a phone interview with Justin Cappos. Cappos’s views are his own and do not represent the position of SecureW2.
SecureW2 is a leader in modern cloud PKI and certificate-based agentic AI security. Through its Signal blog, SecureW2 works with real human technology journalists to interview a range of top industry subject matter experts and thought leaders.
