Self-hosted IAM in Europe: what “sovereign” really means for your keys and data

Every identity vendor now says “sovereign”. The word is on slides, in tenders and in board questions, and it means something different each time. For an identity provider (IdP) it is worth being precise, because the IdP decides who gets into every system you run, and the keys it signs with decide which of its answers anyone will believe.

This article breaks sovereignty into three things you can check: who runs the software, where the data lives, and who holds the signing keys. It describes how we built HelixIAM around them, and where the work stays with you.

Sovereign is not a hosting label

A European data centre does not make an identity system sovereign. Three questions do more work.

1. Who operates it? If the IdP is a service run by someone else, they decide when it updates, where it runs and who can reach it.
2. Where does the data live? Users, sessions, consents and the audit trail are some of the most sensitive records you have.
3. Who holds the keys? Every token, SAML assertion and credential that your IdP signs is only as trustworthy as the private key behind it. Whoever controls that key can produce a valid login.

Most conversations stop at the first question. The third is the one that is hardest to change later.

Layer 1: you run it, on your infrastructure

HelixIAM is self-hosted on your own infrastructure: you decide where data lives, and there is no telemetry. It is delivered as a Helm chart with high availability built in, and it runs on PostgreSQL, with Redis optional and no message broker. That is a small footprint to own: a database you probably already operate, and a stateless server in front of it.

KubeDNA, the Dutch company behind HelixIAM, offers deployment and operations support for HelixIAM on your own or a European cloud, with the scope set per contract. You can run it entirely yourself, or you can have us help. The software and the data stay where you put them either way.

A word of care on what self-hosting does and does not give you. It means you choose the location, and that nothing is reported home. It is not a legal guarantee of data residency, and we do not promise one: where data ends up also depends on how you build the rest of your stack, such as your backups, your mail relay and any third-party services you connect. Self-hosting gives you the control to get it right. It does not do the arranging for you.

Layer 2: the keys, in three custody profiles

Signing keys are where sovereignty gets concrete. In HelixIAM every tenant (a realm) has its own signing keys with safe rotation, and you can bring your own CA-signed keys. On top of that you choose, per realm, where the private keys live.

Profile	Where the private keys live
Standard	Generated in the server and stored encrypted in the database.
Protected	Stored in the database only wrapped by a key-encryption key (KEK) that sits in your HSM or Vault.
High assurance	Generated inside your HSM or Vault and never leaving it. Signing is done by that backend.

The backends are the ones security teams already run: you keep signing keys in your HSM over PKCS#11, or in HashiCorp Vault or OpenBao Transit.

The profiles are a ladder, not a quality scale. Standard is a reasonable starting point for a first application. Protected keeps the key that unwraps the stored keys in your HSM or Vault, outside the database. High assurance moves the private key out of reach of the application server altogether, at the price of a call to your key store for each signature, which is a trade you should make deliberately, per realm, for the realms that need it.

Two further capabilities matter once you run this in earnest:

• Online KEK rotation. You can rotate key-encryption keys online, without downtime. Rotating the key that wraps everything else is the kind of task teams postpone for years when it needs a maintenance window.
• Beyond the sign-in keys. Credential-issuer and eID connection keys can sit in your HSM or Vault too, so the keys behind your European eID connections follow the same custody policy as your token keys.

We keep our claims about hardware modest. We do not name HSM models as supported. When a customer has a specific model in mind, we validate it together in a pilot, on your hardware, before anyone depends on it.

Layer 3: one tenant, one realm, one key store

Many organisations run identity for more than one party: several brands, several agencies, or one customer per tenant when you are a service provider. HelixIAM is multi-tenant by design: each tenant gets its own realm, users, keys and branding.

The isolation can now extend into the key store. A dedicated HSM partition or Vault credential per tenant means that tenant A’s keys are not just logically separate in the application, they are separate in the backend, with their own credential. For a cloud provider or managed-service provider this is the difference between “we host many customers on shared infrastructure” and “each customer has a key store of their own”.

Layer 4: the evidence side

Sovereignty is also about being able to show what happened. HelixIAM keeps a searchable audit log of sign-ins and admin changes, and you can stream audit events to your SIEM over HTTPS, with HMAC-signed webhooks. The log sits in your environment, under your retention rules. On our roadmap are native integrations for syslog, Splunk and Kafka, so audit events can reach the tools your security team already uses without a custom webhook receiver.

On the supply-chain side, every release is cosign-signed with an attested SBOM, so you can check what you are about to run. We say the same about testing as about everything else here, plainly: the software is built with security reviews and automated security testing in CI, and an independent penetration test is in preparation. We would rather give you the current state than a label.

What stays with you

Honest sovereignty means naming the work that stays on your side of the table:

• Operating the key store. An HSM or a Vault cluster has to be run, backed up and monitored. HelixIAM uses it. It does not take that job away.
• Deciding what counts as sovereign. Which HSM, which Vault deployment and which data centre meet your own policy is your decision, not ours.
• Your own assurance. HelixIAM runs inside your environment and under your own information-security management. Your own controls apply to how it runs.
• European eID agreements. DigiD, eHerkenning and eIDAS connectors are included, but you connect them with your own Logius or broker agreement.

If you read a sovereignty pitch that has no such list, ask where it went.

A checklist you can take to any vendor

Use these questions for HelixIAM and for everyone else:

1. Can I run it on infrastructure I choose, and does it phone home?
2. In which profile are signing keys kept, and can I choose it per tenant?
3. Can the private key be generated in, and never leave, my HSM or Vault?
4. Can I rotate the key that wraps my keys without a maintenance window?
5. Is each tenant isolated in the key store as well as in the application?
6. Which claims does the vendor decline to make, and why?

How to start

You do not need to replace everything at once. We suggest three steps.

1. A technical demo. Our engineers show a realm moving through the key-custody profiles on a running system, against a Vault or an HSM.
2. Your use case. We map your tenants, your key-custody requirements and your existing directory to a realm layout.
3. A paid pilot. If it fits, a pilot on your own infrastructure with success criteria agreed up front.

HelixIAM is in early access, and we are now onboarding launch partners. If “sovereign” on your shortlist still lacks an answer about the keys, a demo is a good place to start.