Blog1 April 20266 min read
Sovereignty as a feature, not a marketing line
European cryptographic sovereignty is not a slogan. It is a procurement constraint, a regulatory direction, and an architectural choice. We treat it as all three.
European cryptographic sovereignty has been talked about for two decades. For most of that time, the talk has been ahead of the reality. The cryptographic primitives most European critical-infrastructure operators relied on were, and largely still are, supplied by third parties outside their own jurisdiction: vendors, certification authorities and cloud platforms whose keys, roots of trust and update channels the operators did not control.
That is changing, and the change is not driven by any single dramatic event. It is driven by a confluence: NIS2, CER, eIDAS 2.0, the emerging Cyber Resilience Act, the post-quantum migration mandate, and a genuine procurement appetite among European critical-infrastructure operators to control more of the stack they depend on.
The procurement language has caught up. We are seeing tender documents from European energy operators that ask, plainly, whether the cryptographic primitives in the proposed system depend on a US authority for any part of their operation, and whether the system can operate inside an EU jurisdiction without legal or technical reach-back outside it. Five years ago, this question would have been decorative. Today it is dispositive.
Building a system that is sovereign by design — not retroactively wrapped, not 'EU-region' as a marketing label — is an architectural choice. It is the choice we made.
The DSSA protocol uses NIST-standardised post-quantum primitives, but we do not depend on a third party binding. We are based in Helsinki, our company is Finnish, our infrastructure is European. In a self-operated deployment the cryptographic state lives only in the endpoints — no service we operate holds it. Our hosted service is the deliberate exception: there, we hold the secret of each fleet we run for a customer.
We are not anti-American. There is excellent work in NIST FIPS 203/204/205, and EdSSA's post-quantum handshake uses FIPS 203 (ML-KEM). We are pro-sovereignty, in the sense that operators who need to control where their cryptographic dependencies live should be able to control it. That is a feature, not a marketing line.
If you operate critical infrastructure under European jurisdiction, and the sovereignty box on your procurement scoresheet has been a yellow flag rather than a green check — talk to us.