Earlier this month the OpenSSL Conference returned to Prague, our home city, for its second edition. Across four packed days maintainers, researchers, and vendors kept circling the same problem: hardware stays in the field far longer than the cryptography and the rules around it stand still. These are the insights we brought back, and what they mean for anyone building devices that have to stay trustworthy for years.

Post-quantum on a device you can hold

Our Firmware Lead, Jan Medek, joined a tutorial about turning a blank USB key into a hybrid post-quantum FIDO2 passkey and verifying both of its signatures with OpenSSL. The token runs research firmware with no secure element. That’s a layer we're interested in applying TROPIC01 as the chip has applications in hardware PIN verification. A production version of a token like this would need it. 

Seeing the USB key made the scale of the post-quantum (PQC) shift concrete. PQC signatures are far larger than today's, and everything around them, from transport frames to stack memory, has to grow to fit. With ML-DSA standardised as FIPS 204 in August 2024, PQC capabilities have begun moving into hardware, and secure elements will have to carry them within tight memory budgets. For us this was a hands-on look at what implementing PQC will take, particularly as our TROPIC01 chip doesn't do post-quantum signing itself.

Our own session

On Wednesday, our Head of Product, Pavel Polach, and Maxim Kostin from Solutions and Business Development presented "Engineering Reality of CRA Compliance for Linux-based IoT Solutions". They took a stock OpenWrt One router and set out to make it secure by design rather than compliant only on paper in the spirit of the CRA. The talk was open about where our own assumptions turned out to be wrong, and it sparked plenty of debate in the room.

If you want to check out Pavel and Maxim's work, the reference image and CRA related packages for OpenWRT they produced can be viewed on this Github repo. 

Plan migrations around device lifetimes, not release cycles

Several talks made the same point from different angles: the industry is in the middle of its largest cryptographic migration since crypto became essential to the internet, and much of the affected hardware will stay in service for anywhere from five to twenty-plus years. Devices that are hard to update leave a backlog that keeps growing. The advice we heard most was to plan the PQC transition deliberately rather than rush it. The new algorithms differ from today's in size and behaviour, and those differences reach all the way down to the silicon.

CRA expertise is landing on engineers first

The sessions on the EU Cyber Resilience Act, and the questions after them, showed how much practical CRA knowledge now sits with product-security engineers, so compliance has to be a joint effort with legal.

One case put to the room: a supplier reports a vulnerability in a component, and your team finds it doesn't affect your product. Do you notify the coordinating CSIRT and ENISA? Our representative answered that one from the floor — No! CRA article 14 covers actively exploited vulnerabilities contained in your product, so a flaw in a secure element feature your design never touches, such as general-purpose storage, doesn't automatically become your obligation.

The clock is already running: Article 14 reporting duties have applied since 11 September 2026, including to products already on the market, and the rest of the regulation applies from 11 December 2027.

Why we collaborate with OpenSSL Corporation

Tropic Square’s presence at the OpenSSL conference is one part of an ongoing cooperation between our company and the OpenSSL Corporation. A week like this shows why it matters to both of us; secure hardware and the open-source cryptography running on it need to work together. We’re grateful to the OpenSSL Corporation for putting the people tackling the hard problems, particularly PQC migration and CRA compliance, in one room.