This page is available in French. Voir en français

Notes · 1 August 2026

A revocable key that is not a kill-switch

How to make a usage right revocable without building a remote channel into a sovereign deployment — and why the difference matters.

A vendor that can revoke a licence from afar has, by construction, a channel into the customer's system. For most software that is unremarkable. For sovereign infrastructure — a deployment an institution runs on its own hardware, possibly air-gapped — it is a contradiction: the very channel that enables instant remote revocation is the channel that breaks the promise of sovereignty.

The tension, stated plainly

You want two things that pull apart. You want the institution to hold its own system with no outside control channel. And you want usage rights that can expire or be withdrawn. A naive design resolves the tension by adding a channel — and quietly loses the first property to gain the second.

Resolve it with a signed certificate, verified locally

The alternative is to make the usage right a signed usage-rights certificate that the deployment verifies locally. The institution holds only the public key needed to check it. There is no channel in; there is a document that the system reads. Revocation, where it applies, is a signed statement the institution can import — connected or by hand — not a remote command.

What revocation may and may not touch

The line that makes this safe is simple. Revocation blocks new sensitive actions. It never blocks the institution's access to its own data, and it never prevents the institution from stopping the system. A right that could lock an institution out of its own records, or keep it from pulling its own emergency stop, would not be a licence term — it would be the backdoor the design set out to avoid.

Request a briefing