Preparing for the quantum era requires more than identifying the threat and selecting new cryptographic algorithms. Quantum-resistant solutions must also work within existing infrastructures, meet the requirements of different sectors and remain reliable under real-world operating conditions.
This is the challenge Q-FENCE is addressing through a combination of cryptographic research, hardware and software development, and testing across five real-world pilots. The Horizon Europe project brings together fifteen partners across ten countries, combining academic expertise with industrial experience to explore how quantum-resistant security can move from research into practice.
In the second part of our conversation, Indrakshi Dey, project coordinator at Walton Institute, South East Technological University in Ireland, explains what distinguishes Q-FENCE’s approach, what its pilots are designed to demonstrate and what the first year has taught the consortium about delivering European research collaboratively.
Building on Europe’s collective effort
What are Q-FENCE’s key strengths, and what makes its approach distinctive?
There is a strong European effort in this space, and I would frame our position as complementary rather than competitive. Q-FENCE is part of the SPQR cluster, Secure Post Quantum eRa, alongside QUBIP, PQ-NEXT, FOCAL, QARC, POSEIDON and FORTRESS. We meet every six weeks to coordinate and share results, and Europe is stronger for having these projects tackle different layers of the same problem. What distinguishes Q-FENCE is, first, genuine hardware and software co-design. Many initiatives work at the protocol or software layer. We work from the lattice mathematics all the way down to FPGA and RISC-V implementations, because a root of trust that exists only in software is a weaker root of trust. Second, we treat quantum technology as an ingredient and not only as a threat. Quantum random number generation supplies our entropy, quantum key distribution is integrated in one of our pilots, and we use the Mermin-Peres magic square game as a mechanism for detecting interference on a communication channel. Very few projects combine post-quantum mathematics with quantum-derived randomness in this way. Third, the breadth of validation, five regulated sectors in five countries rather than a single domain, and a compliance-first orientation that maps our work onto GDPR, NIS2 and PSD2 while feeding results into NIST, ETSI, CEN/CENELEC and our ongoing engagement with the European Cybersecurity Competence Centre. Finally, the consortium itself. Having Toshiba, Red Hat, Telespazio and Fraunhofer IPMS working directly alongside academic cryptographers means results are pressure-tested against commercial and operational reality from the outset, rather than at the end.
That combination of expertise is central to the project’s approach. Developing a framework is one thing; understanding how it behaves under different operational constraints is another. Q-FENCE is therefore testing its work across five sectors, each of which brings its own requirements and challenges.
Five pilots, five different environments
What can we learn from testing across finance, healthcare, smart cities, satellite and enterprise networks?
Our five pilots were chosen precisely because they fail in different ways. In finance, we are building secure multi-party computation that lets regulators spot suspicious patterns for anti-money-laundering purposes without ever accessing raw data from individual institutions, with a tamper-proof audit trail carrying post-quantum signatures. In healthcare, in the Silesia region of Poland, we are enabling encrypted medical data to be shared and processed remotely, drawing on anonymised datasets from European data space initiatives. In smart cities, we are deploying across roughly a thousand IoT devices in a Geneva testbed. In space, we are securing a satellite ground link between Telespazio’s Fucino Space Centre and Rome. And in enterprise networks, we are integrating quantum key distribution with our framework across a fibre link running between Waterford, Cork and Dublin. Each environment imposes a different binding constraint. IoT sensors are limited by energy and memory. Satellite links are defined by latency and by cross-border regulatory complexity. Finance is dominated by auditability and by PSD2 and anti-money-laundering obligations. Healthcare turns on GDPR and on interoperability between systems that were never designed to talk to each other. Enterprise networks are about distributing keys reliably at scale. This matters because a cryptographic scheme that performs beautifully in a data centre can be unusable on a battery-powered sensor, and a protocol tuned for low latency may behave quite differently across a high-latency satellite hop. Testing in only one environment would let us optimise for that environment and then mistakenly describe the result as general-purpose. Working across all five forces the framework to be genuinely adaptable, and it lets us produce best-practice guidance that speaks to each sector’s real conditions rather than offering generic advice that no one can act on.
The pilots highlight how much depends on the devices and systems that implement cryptographic protection. This is particularly important for environments such as smart cities and space, where devices may be physically exposed or impossible to access once deployed. It also helps explain why Q-FENCE looks beyond software to the hardware that establishes and protects a device’s identity.
Establishing trust at the hardware level
Why does hardware matter? What can a physical root of trust do that software alone cannot?
Trust anchored only in software is circular. The software that verifies system integrity can itself be modified by an attacker who has gained sufficient access, so at some point the chain has to terminate in something that is not software. That is what a Physically Unclonable Function provides. It derives a key from microscopic manufacturing variations that are unique to each individual chip and effectively impossible to reproduce, even by the manufacturer. The key is not stored anywhere. It is regenerated on demand, which means there is nothing sitting in memory to extract. This matters enormously for devices in physically exposed locations, such as sensors on a city street, or in locations nobody can reach at all, such as a satellite in orbit. Hardware helps in two further ways. Post-quantum secure boot lets a device verify the authenticity of its own firmware at startup, so only trusted code runs and the update path cannot be used as an attack route. And dedicated accelerators keep post-quantum cryptography fast enough to be usable on constrained devices, with constant-time and dual-rail logic to resist side-channel attacks, which target the implementation rather than the mathematics. The same logic applies to randomness: a strong algorithm seeded by a weak random number generator is still weak, which is why we use quantum random number generation for genuine physical entropy.
The technical work is only one part of developing and deploying such a framework. A project of this scale must also align different organisations, manage shared responsibilities and translate research objectives into practical results. Looking back on the first year, Indrakshi reflects on some of the challenges that have emerged beyond the technical work itself.
Lessons from the first year
What has surprised you most in the first year of coordinating the project?
How much of the first year is institutional rather than technical. Our consortium agreement went through five full revisions between July and December 2025, with legal reviews from almost every partner. At moments that felt slow relative to the urgency of the problem we are trying to solve. In hindsight it was time well spent, because that document determines who owns what and who can access what, and those terms decide whether the results can actually be exploited once we have them. The second surprise was how much the conversation outside the project has shifted. When we were writing the proposal, a good deal of effort went into persuading people that the quantum threat was real and worth planning for. That argument now needs making far less often. Organisations are asking what to do on Monday morning, not whether the problem exists, and the demand has moved from awareness to practical migration guidance faster than I expected. The third is more technical. In almost every pilot, the constraint that bites first is not cryptographic strength. It is integration: legacy compatibility, memory, power budgets and interoperability between systems that were never designed to talk to each other.
These experiences underline the importance of coordination in a project where research, engineering, regulation and industrial deployment intersect. With fifteen partners working across ten countries, establishing a shared direction and making sure each partner can contribute its expertise are essential to keeping the work moving forward.
Making a European consortium work
Coordinating fifteen partners across ten countries is a considerable undertaking. What makes a European consortium work well in practice?
The honest answer is that it works when the boring parts are done properly and early. We run working groups aligned to each work package, monthly technical coordination, quarterly governance meetings, a risk register reviewed every month and internal checkpoints every six months. None of this is glamorous, but it removes ambiguity about who decides what, and ambiguity is what actually derails large collaborations. Complementarity matters more than size. Our partners were chosen so that contributions add rather than overlap: cryptographic theory, hardware design, systems integration, sector expertise and policy engagement each have a clear home. When two partners are quietly doing the same work, effort is wasted and friction follows. Getting people physically together early also makes a measurable difference. We opened with a two-day all-partner meeting in Waterford, and the relationships formed there have carried a year’s worth of remote collaboration. The last point is about recognising that success means different things to different partners. A university group is measured on publications and doctoral training, an industrial partner on product roadmaps and market position. Good coordination does not paper over that difference. It makes room for both, so that everyone has a reason to keep showing up.
Q-FENCE’s work shows that preparing for quantum-resistant security involves more than developing new algorithms. It requires technologies that can function under real-world constraints, testing across different sectors, and collaboration between researchers, technology providers and organisations responsible for critical digital infrastructure.
By combining these elements, the project aims to help bridge the gap between post-quantum cryptographic standards and their practical deployment, supporting a more adaptable and resilient European digital infrastructure.