Why I'm building Shorium

I don’t usually write about my own companies here.

This time, I have a good reason to make an exception.

For the past few months, much of my work has been going into Shorium, a cybersecurity company I’m building as Co-founder and CTO.

It’s an interesting place to find myself after twenty-five years working in product design, technology and human-computer interaction.

But the more I work on it, the more I realise that the problems we’re trying to solve are closely related to the ones I’ve been interested in throughout my career.

They just happen to involve cryptography, connected devices and a rather uncomfortable question about the future of digital trust.

A product doesn’t have to break to become insecure

Think about a connected product.

It could be a payment terminal, an industrial sensor, a medical device or a car.

When we interact with these products, we see what they do. We rarely see the systems that allow them to operate securely. Behind the interface, there’s hardware, firmware, software, certificates, cryptographic keys, identities, suppliers and update mechanisms.

All of these components depend on each other.

And many of those dependencies are based on assumptions made when the product was originally designed.

Now imagine that product operating for fifteen years.

During that time, certificates expire, algorithms become obsolete, suppliers change, vulnerabilities are discovered and regulations evolve. The product might continue to work perfectly. It turns on. It connects. It performs its function. From the user’s perspective, nothing has changed.

But underneath, the conditions that made it trustworthy may no longer exist.

A functioning system isn’t necessarily a trustworthy system.

I’ve spent a large part of my career designing products that need to remain understandable and usable as they become more complex.

One thing I’ve learned is that complexity doesn’t disappear simply because we stop showing it. In security, that hidden complexity can become a serious problem.

Especially when nobody can clearly explain what depends on what.

Quantum computing isn’t the real starting point

Whenever post-quantum cryptography comes up, the conversation tends to move immediately toward quantum computers.

• When will they become powerful enough to break today’s cryptography?
• Five years? Ten? Twenty?

I find the question interesting, but from an engineering perspective, it’s not where I would start. We already know that widely deployed public-key cryptographic systems will need to migrate.

NIST published its first post-quantum cryptography standards in 2024. The European Union has established a coordinated roadmap, with 2030 as an important milestone for high-risk use cases.

The transition has started, regardless of when a sufficiently powerful quantum computer becomes available.

And the difficulty isn’t simply choosing a new algorithm.

Imagine replacing the cryptography used by an industrial device that has already been deployed across thousands of installations.

• Its firmware might depend on a particular signing mechanism.
• Its hardware might not support the new algorithm.
• Its identity could depend on certificates issued through an existing infrastructure.
• Its update process might involve several suppliers.

Changing one component could affect the entire chain.

You can’t approach that kind of migration as though you were updating an application on your laptop.

And you certainly can’t assume that every device can be recalled, replaced or taken offline. We’re trying to change fundamental security mechanisms inside systems that must continue operating.

Cryptographic continuity

This is where Shorium comes in.

The name comes from Shor’s algorithm, which demonstrated how a sufficiently capable quantum computer could break widely used public-key cryptographic systems.

There’s something I like about naming a company after the algorithm that exposed the problem.

Because we’re not building a company around the idea that cryptography will never break. We’re building around the idea that trust needs to survive change.

Shorium’s focus is cryptographic continuity.

In practical terms, we’re developing a platform designed to discover, model and manage the cryptographic trust relationships inside connected products.

The central concept is something we call the Trust Twin.

Think of it as a living model of the cryptographic dependencies that support a product.

Not just an inventory of certificates or algorithms.

A representation of how those elements relate to each other.

• Which key signs which firmware?
• Which certificate establishes which identity?
• Which components depend on a particular cryptographic mechanism?
• What happens when an algorithm is deprecated?
• What changes when a supplier replaces a component?
• And how can we demonstrate that a product remains trustworthy after those changes?

These questions are difficult to answer when information is distributed across engineering teams, manufacturing systems, suppliers and documentation.

Our approach is organised around four capabilities: Observe, Connect, Simulate and Orchestrate.

• First, discover the relevant cryptographic signals.
• Then reconstruct the relationships between them.
• Use those relationships to evaluate the potential impact of changes.
• And finally, support teams in planning and coordinating the transition while preserving evidence of what happened.

The objective is not to produce another dashboard full of green indicators.

It’s to make cryptographic continuity something engineers can understand, evaluate and demonstrate.

There’s an important distinction here: this is the architecture and product direction we’re building toward. We’re an early-stage company, and I don’t want to confuse a technical vision with a finished, validated product.

But the problem is real, and the direction is clear.

Why a product designer is working on cryptography

I’m not a cryptographer.

And I don’t intend to pretend otherwise.

We have people at Shorium who have spent years working on cryptographic research. My job is different. I’ve spent approximately twenty-five years designing digital products, interfaces and complex systems.

I’ve worked across different industries, from digital services to enterprise software and embedded cybersecurity. For three years, I was Design Lead at Exein, working on products in an environment where the relationship between hardware, software and security is particularly important.

And throughout those years, I’ve kept returning to the same problem.

Technology becomes useful when people can understand what they’re doing with it.

That might sound obvious.

In practice, it isn’t.

I’ve seen technically sophisticated products become unnecessarily difficult to operate because their architecture made sense to the engineers who built them but not to the people responsible for using them.

I’ve also seen the opposite: interfaces designed to look simple that hide so much complexity that users lose the ability to understand what’s actually happening.

Neither is particularly good design.

And in cybersecurity, both can become dangerous.

Imagine you’re responsible for the security of several thousand connected devices.

A cryptographic algorithm needs to be replaced.

You have a list of affected products, several engineering teams, suppliers, compliance requirements and a deadline. You don’t need a beautiful interface telling you that something is wrong.

You need to understand the consequences of your decisions.

• Which devices are affected?
• What can be changed?
• What cannot?
• What happens if you migrate one dependency before another?
• Can you demonstrate that the system remains secure afterwards?
• This is where I see the connection between my background and what we’re building.

My responsibility as CTO isn’t simply to make sure we choose the right technologies.

It’s to help build an architecture where scientific correctness, engineering constraints and human decision-making can coexist.

• The cryptography needs to be sound.
• The software needs to be reliable.
• And the people operating it need to understand enough of the system to make informed decisions.

That’s not something you solve by adding a nicer dashboard at the end of development.

It needs to influence the architecture from the beginning.

Making complexity understandable is not the same as hiding it

There’s a principle I’ve followed for years in product design.

Don’t make something look simple by removing the information people need.

Make it understandable.

I think this distinction is particularly relevant now, as more software products introduce automation and AI into increasingly complex workflows.

We have become very good at making systems produce answers.

We’re not always as good at helping people understand where those answers came from, what assumptions they depend on or what happens when those assumptions change. For a consumer application, that might create a frustrating experience. For a security-critical system, the consequences can be much more serious.

At Shorium, this influences how I think about the Trust Twin.

A model of cryptographic dependencies is useful only if it helps someone reason about the system.

It’s not enough to discover a relationship.

We need to understand its origin, its context and what evidence supports it.

If a dependency changes, the system should help explain the consequences.

If a recommendation is made, the people responsible for acting on it need enough information to evaluate it. And when a decision is taken, there needs to be a way to reconstruct what happened. That last part matters more than it might seem.

In cybersecurity, being able to explain a decision six months later can be just as important as making the decision correctly in the first place.

This is why I find the intersection of product design, software architecture and security so interesting.

Good design isn’t decoration applied to engineering.

It’s part of how a system communicates its own behaviour.

And sometimes it’s what makes the difference between having information and being able to act on it.

The people behind Shorium

One of the reasons I decided to take on this challenge is the team.

Danilo Bontà, our Founder & CEO, has spent more than fifteen years working across cybersecurity and international technology. His experience includes building Moodle’s global partner ecosystem, working across Asia-Pacific and collaborating with institutions including NATO and government organisations.

Dan and I previously worked together at Exein.

We already knew each other’s way of approaching problems, and we shared an interest in what happens when cybersecurity has to work inside real products rather than theoretical architectures.

Dariia Porechna, Co-founder & Chief Scientific Officer, comes from a very different background.

She’s a post-quantum cryptographer who spent six years at Wolfram Research, working with Stephen Wolfram and developing cryptographic functionality for the Wolfram Language. She’s also a co-author of SILMARILS, a post-quantum digital signature construction. Dariia brings the scientific foundations that a product like Shorium needs.

Our broader team also includes cryptographic researchers, engineers and people responsible for turning that research into something we can build and operate.

I like working in this kind of environment.

People who approach the same problem with different mental models tend to ask different questions.

A cryptographer might ask whether a construction is mathematically sound.

An engineer might ask whether it can be implemented reliably within the constraints of a particular device.

A product designer might ask whether the person responsible for that device can understand what needs to happen next.

All three questions matter.

And as CTO, part of my responsibility is making sure they don’t become three separate conversations.

Why this is also a brownfield problem

There’s another reason I’m writing about Shorium here.

Most of the technology industry likes talking about new things.

New architectures. New frameworks. New infrastructure. New products.

We tend to describe technological progress as though everything begins with a clean environment and a perfectly designed system.

It rarely does. Real organisations have existing products. Existing infrastructure. Existing suppliers, processes, certifications and technical decisions made years ago.

Some of those decisions were perfectly reasonable when they were made. Others were compromises. And some have become difficult to change because too many things now depend on them.

This is the reality of brownfield engineering. You don’t get to redesign everything from scratch. You inherit a system, understand its constraints and find a way to evolve it without destroying what already works.

The post-quantum transition is a particularly interesting example. We aren’t going to replace the world’s cryptographic infrastructure overnight. We’ll have to migrate it while it’s running. Some products will be easy to update.

Others will require changes to firmware, hardware, manufacturing processes or entire chains of trust. Some will remain deployed long after their original designers have moved on.

And throughout that process, manufacturers will still need to maintain security, availability and compliance. For me, this is much more interesting than the usual discussion about when quantum computers will become powerful enough to break current cryptography.

The real engineering work begins long before that happens.

And it happens inside systems that already exist.

Becoming a CTO didn’t mean leaving design behind

There’s something else I want to address, because it’s relevant to how I see my role.

I’ve spent most of my professional life being identified as a designer.

Product Designer. UX Designer. Design Lead.

Those titles have changed over time, but the underlying work has always involved understanding systems, their constraints and the people interacting with them.

I’ve never considered design to be limited to interfaces.

An interface is simply the part of a system that becomes visible.

Behind it are decisions about architecture, information, behaviour, performance, reliability and the way different components interact.

You can’t design a good experience without understanding at least some of those decisions.

And the more complex the product becomes, the less useful it is to treat design and engineering as completely separate disciplines.

Moving into the CTO role at Shorium hasn’t changed that perspective.

It’s extended it.

Today I’m spending much more time thinking about architecture, technology choices, engineering processes and how to build a platform that can evolve without accumulating unnecessary complexity.

Performance matters to me. So does maintainability. So does the ability to understand why a system behaves the way it does.

I still care about interfaces, of course.

But I’m equally interested in what happens before anything reaches the screen.

• How data is collected.
• How relationships are represented.
• How systems communicate.
• How evidence is preserved.
• How we avoid creating dependencies that will become problems later.
• And how we build something that remains understandable as it grows.

I don’t see that as moving away from design.

I see it as applying the same way of thinking at a different level of the system.

Perhaps that’s the most interesting part of this transition for me.

After twenty-five years, I’m still working on the relationship between people and technology.

I’m just working much further down the stack.

Where we go from here

Shorium is still early.

We’re building the company in Turin, developing the platform and working through the scientific and engineering challenges involved.

There are things we know. There are things we still need to validate. And there are plenty of difficult decisions ahead.

I’m not particularly interested in announcing capabilities before they exist or pretending that building a technically ambitious product is straightforward.

It isn’t.

Especially when you’re working at the intersection of cryptography, embedded systems, software architecture and regulatory requirements.

But I think the underlying problem is worth solving.

For years, we’ve treated security as something that can be assessed at a particular moment.

• A product passes an audit.
• A certificate is valid.
• An algorithm is considered secure.
• A device meets a standard.
• And then time passes.
• The product changes.
• Its dependencies change.
• The world around it changes.

The question is whether we can build systems that understand those changes well enough to maintain trust throughout their lifecycle.

That’s what we’re trying to do at Shorium.

And it’s why I’ve decided to spend the next part of my career working on it.

A product can keep working long after the assumptions that made it trustworthy have changed.

I think we should be able to know when that happens.

Preferably before something breaks.

Shorium — Cybersecurity for Continuity

Originally published on Brownfield AI.