Hello readers!

This week, we’re talking about post-quantum encryption, SGP.32, how IoT is changing payment processing, and more!

Changing a cryptographic standard used to be a software problem. Security teams patched servers, rotated certificates and retired old protocols on a schedule that IT controlled. The move to post-quantum cryptography runs on a different clock, one set by the oldest connected hardware still in service. In a hospital, that hardware includes infusion pumps, patient monitors, imaging systems and lab analyzers. These devices can stay on the network for many years and sit inside clinical workflows, and few were built to swap out the math that protects their traffic. Two timelines now have to line up: how long a device stays installed, and how long the data it handles stays sensitive. Healthcare is where those timelines collide first, because a diagnostic image or a medication history stays private for decades. For connected-device teams, the question is now less about when a quantum computer could break today’s encryption and more about how much of their installed base can still change its encryption by then.

New numbers show how wide that gap is. Forescout’s Vedere Labs analyzed more than 2.5 million devices across over 50 healthcare delivery organizations. Only 6% of Internet of Medical Things devices running SSH use implementations that can support post-quantum cryptography. Operational technology came in at 16%, while conventional IT sat at 50%. The exposure extends beyond the firewall, too. Researchers counted more than 5,500 internet-facing healthcare systems, and most were medical record platforms and imaging archives. Only 31% of those systems supported TLS 1.3, the protocol version that standardized post-quantum key exchange depends on. The split between IT and medical devices follows replacement cycles more than security effort. Servers and enterprise software get migrated on a normal refresh cadence. A specialized device with a restricted upgrade path, vendor certification constraints and a clinical team that depends on it stays put. That is why the report expects some medical equipment never to receive native post-quantum support at all.

The threat behind that timeline is already active, even though the machine that would carry it out doesn’t exist yet. The “harvest now, decrypt later” model only requires an attacker to capture encrypted traffic today and wait. A stolen password can be reset, but a patient’s lab history can’t be reissued. IoT For All contributor Alex Vakulov made the same lifecycle point about IoT broadly in a piece on post-quantum encryption strategies. Devices often stay in operation for a decade or more, he noted. Symmetric ciphers like AES hold up against quantum attacks with longer keys, so the real exposure sits in the asymmetric methods used for key exchange and authentication. The replacement algorithms already exist, since NIST finalized its first three post-quantum standards in 2024. What hospitals lack is a way to install them on equipment that was certified, deployed and then largely left alone. Vakulov’s answer for low-bandwidth sensors is to pre-provision symmetric keys in a secure element. That works when trust relationships are fixed at the factory. It does little for a ten-year-old imaging workstation already on the floor.

That leaves network architecture to carry the load, and architecture starts with knowing what’s on the network. Forescout’s recommendations begin with asset inventory and classification. From there, teams should prioritize internet-facing systems, enable TLS 1.3 where possible, and plan segmentation, restricted access and closer monitoring for anything that can’t be upgraded. Hospitals have historically struggled with that first step. An IoT For All analysis of IoMT asset risk found that manual inventories are impractical to keep current. It also found that identifying devices by MAC address leaves some misidentified or missed entirely, so security teams end up rating risk without a full picture of what they’re rating. Post-quantum planning raises the stakes on that visibility, because it adds a new attribute to track for every device: whether its cryptography can change in the field. For connected products sold in Europe, regulators are writing that responsibility into law. The EU Cyber Resilience Act treats security as an obligation that lasts a product’s expected lifetime. Its vulnerability reporting duties began on September 11 of this year, and the law applies in full from December 2027.

Anyone buying or building long-lived connected equipment is mostly deciding their post-quantum future at purchase time. A device that ships without a way to change its cryptographic algorithms after deployment has locked in its security ceiling for its whole service life. The practical moves are unglamorous. Add crypto-agility to procurement requirements, and ask vendors directly how a device’s key exchange and certificates get updated in the field and for how long they’ll be supported. Build an inventory that records cryptographic capability alongside OS and firmware version, starting with anything that faces the internet or touches records and images. For devices that will never get native post-quantum support, write the segmentation and monitoring plan now, while there’s still time to test it without a deadline attached. Hospitals are the clearest early case. The same arithmetic applies to smart meters, industrial controllers and any fleet expected to outlast the encryption it shipped with.

If you've attended an IoT connectivity event in the past 12 months, you've probably heard the ever-present chatter around SGP.32. The new GSMA eSIM standard promises greater flexibility through remote profile management, leading many organisations to view it as the next major step in global IoT connectivity.

Read more

In this episode of the IoT For All Podcast, Patrick Ferriter, SVP of Product at Agora, joins Ryan Chacon to discuss building real-time voice AI experiences, even on bad networks. The conversation covers what physical AI means, moving from controlled demos to the real world, architecting a voice AI experience for high latency networks, physical AI uses cases, AI companions, using edge or cloud for AI, privacy and security, and the future of conversational AI devices.

YouTube • Spotify • Apple • YT Music • Amazon