The takeaways, in brief
Authentication is the overlooked layer in PQC planning. Encryption and signing get the attention; connecting devices to Wi-Fi, VPN, and the network does not — even though it is the daily front door to the enterprise.
The bottleneck isn’t the certificate — it’s the infrastructure. PQC certificates are four to ten times larger than RSA or ECC ones, and RADIUS over UDP runs into a “4 KB wall” that causes fragmentation and failed authentications. The path forward is RadSec (over TCP) with the encryption channel moved to TLS 1.3.
Start with discovery, and start now. Inventory every device and the cryptography it actually uses — you will find RSA-2048 and even SHA-1 still in production — before building a migration game plan with your IT teams and vendors.
Kalyan Arety has spent more than two decades serving as a cybersecurity product leader, which has given him a front row seat to how modern enterprises think about some of the industry’s biggest issues. He says most post-quantum cryptography (PQC) roadmaps focus on encryption and digital signatures. The layer enterprises run through every day — authenticating a device onto Wi-Fi, the VPN, the network — gets left out.
In this condensed Q&A, Arety walks through the threat vectors that make PQC urgent now, the infrastructure bottlenecks that break authentication when certificates get bigger, and where organizations should actually start.
With AI agents evolving so rapidly, they can sit on the edge — on your Wi-Fi or on the network — and they can harvest your information at scale. When the quantum computers get here, they can easily decrypt all of it.
— Kalyan Arety, SecureW2Most of the discussions I’ve seen in the last two to three years were around the encryption and signing use cases — very little or none about the authentication use case. And authentication is something we go through on a daily basis: connecting a device to Wi-Fi, connecting to the network, to the VPN, securing your enterprise network access. That’s the bare minimum that has to be looked at — and it’s a topic that’s been skipped in most of this conversation.
There is an industry regulation and compliance mandate coming from the government — the CNSA and NIST standards. Then there is the hardware evolution: quantum-ready computers that can easily break an RSA or ECC algorithm within hours. And last but not least, something that has changed drastically in the last year — the advent of agentic AI. A year or two back, I would not have thought of it. We’ve known “harvest now, decrypt later” is a genuine threat, but few would’ve assumed it could scale up so fast before the AI evolution.
There are still state-led actors sponsoring this attack mechanism. It’s a matter of time before most of the network sessions that have already been harvested can be decrypted and attackers can get hold of the key information. With AI agents evolving so rapidly, they can sit on the edge — on your Wi-Fi or on the network — and they can harvest your information at scale. When the quantum computers get here, they can easily decrypt all of it. The threat vector that existed 12 months ago has multiplied 10X with the evolution of AI agents.
On the password side: if you have a password-based authentication, any network sessions that have already been harvested can easily be hacked and the bad actors can easily get hold of your Active Directory passwords. The damage does not stop there. They can easily move laterally to access your Wi-Fi, your VPN, all your emails and applications that are key and critical to your business.
Recently, I think enterprises are starting to wake up to the idea that issuing a PQC-compliant certificate is only one piece of the puzzle. There are lots of things you have to look into — which is actually your network infrastructure, and what parts of your network infrastructure have to be built up to this PQC-compliant journey.
If only one vendor who is part of this entire network infrastructure equation says they are PQC compliant, it’s not good enough for any of these use cases. Everything has to work together — evolve together — to support a PQC journey.
The RADIUS protocol — which is built for 802.1X Wi-Fi authentication — is built on UDP protocol, and UDP as such is written for smaller payloads. With a PQC certificate, the payload is easily four to ten times larger than an ECC or RSA [classic] certificate. Now, the first issue is that when you have this PQC handshake that exceeds your MTU sizes, it can lead to degradation and packet fragmentation. If you push too much water through a pipe, it breaks — the same thing happens with a PQC-sized payload. Authentication timeouts go up because if the RADIUS controller does not have enough capability to process large signatures, authentication requests tend to fall through the cracks.
The second problem is that RADIUS over UDP has a 4 KB limit, and a PQC payload is four to ten times larger than a classic payload. To handle it, you have to break the payload into multiple fragments — and if even a single fragment is lost in transit, the entire authentication request fails. It can even happen that when it fails, the controller ends up requesting authentication again and again and gets into an infinite authentication loop, which leads to session timeouts. I call it the 4 KB wall.
The UDP protocol is no good — it has its own limitations on handling large payloads. Effectively, moving to RadSec utilizes TCP, and TCP does not have that limitation on handling a bigger payload. That’s the first part of the journey. With RadSec, your pipeline is secure — any communication between the RADIUS server and the access point is encrypted.
The second question is the payload itself: when it is encrypted, the [older] cipher suite standards are inferior in a post-quantum crypto world. That’s where it has to move to TLS 1.3. Your encryption channel between your RADIUS service and the access point has to be TLS 1.3 compliant. That’s when you have a RADIUS service that can handle the PQC payload and is compliant to the PQC standards. Any data being harvested by bad actors — if you’re on TLS 1.3, it is safe. If you’re on TLS 1.1 or TLS 1.2, you’re very susceptible in a post-quantum crypto world.
I would start today. The first part of the journey is your discovery and visibility. If you don’t have visibility to all your devices — what kind of crypto is being used, is it RSA — I’m pretty sure when you look and discover all your devices and see what encryption standards they have, you’ll be up for a surprise. Some of them will even have RSA 2048, probably even SHA-1 signing. You need to look into your existing infrastructure, discover your devices, what encryption standards are being used, have that intelligence and insight in place, and start from there. I think that would be the first step I would say. And then, yeah, you will have to work with your IT folks, your vendors you work with on your RADIUS service, based on whatever you discovered. That’s where you have to start building your game plan.
The infrastructure surrounding each of those use cases will be different. The Wi-Fi part of it — it’s all your business productivity. It’s about employees, students being able to connect to the Wi-Fi and being productive enough for the company. If your infrastructure — such as access points — does not support handling a PQC payload and it leads to Wi-Fi authentication requests failing, someone working remotely will not be able to deliver their work. Productivity levels fall across the employees for a company. That can be a real showstopper. It’s not just employee productivity — take a retail shop: you have customers coming in and you have to process payments. If those kiosk machines are not connected to the network, the businesses are also going down.
For the server use case, the user persona involved will be different — typically a DevOps or network admin who manages internal-facing load balancing servers. They will have to go through that particular transition in terms of whether those servers have enough computational ability to handle a PQC payload. The rest of the journey would be a bit simpler for them, because if the RADIUS service is ready to issue a PQC-compliant certificate, it’s just a matter of pushing the certificate. But it’s all about handling the PQC payloads — how efficiently it can be done through the RADIUS service.
End of the day, the monitoring of your network traffic would become key — to ensure that PQC payloads don’t fall through the cracks because of the heavy payload. And if you transition to a RadSec solution, that’s where your network traffic can easily be managed through your RADIUS service.
