Skip to content
Sovereign and public sector

Identity that stays in Europe. All of it.

A dedicated deployment in the EU or on your own premises, a European company as your contracting party, and no US processors anywhere in the chain. For the public sector and regulated industries.

Talk to usSee pricing
The problem

Sovereignty can't be a checkbox

An EU region from a US provider is still subject to US law, wherever the servers stand.

Procurement asks who the contracting party is, who the sub-processors are and where support sits.

On a shared platform it is hard to prove where data is, who can reach it and how you would leave.

How Anchr.ing helps

Sovereign by construction

Dedicated, in the EU

Your own deployment on EU infrastructure run by us, or on your premises under licence.

A European contracting party

Your agreement is with Simon ApS, a Danish company, under EU law, with a DPA, support terms and escrow.

No US processors

No US company anywhere in the deployment's processing chain.

Open standards, no lock-in

OpenID Connect, SAML, SCIM and WebAuthn: any standard client works, and so does leaving.

Isolation by design

Separated by the database, not by a filter

Hosted or dedicated, each environment is its own database with its own database user and signing keys. A request reaches only the environment its address names, so test never touches production and a bug in our code can't cross between customers: the database refuses.

Security overview
How customers are kept apartEach customer has its own namespace with separate Test and Production databases. Each environment holds its own users, apps, sessions and tokens, signing key and database user. A request from customer A's production app reaches only A's production database: a query from it towards customer B is refused by the database itself, and test never trusts production. A's production app Anchr.ing server Customer Aown namespace TestUsersAppsSessions, tokensSigning keyDatabase user ProductionUsersAppsSessions, tokensSigning keyDatabase user Test never trusts production Customer Bown namespace TestUsersAppsSessions, tokensSigning keyDatabase user ProductionUsersAppsSessions, tokensSigning keyDatabase user The databaserefuses How customers are kept apartEach customer has its own namespace with separate Test and Production databases. Each environment holds its own users, apps, sessions and tokens, signing key and database user. A request from customer A's production app reaches only A's production database: a query from it towards customer B is refused by the database itself, and test never trusts production. A's production app Anchr.ing server Customer Aown namespace TestUsersAppsSessions, tokensSigning keyDatabase user ProductionUsersAppsSessions, tokensSigning keyDatabase user Test never trusts production Customer Bown namespace Test Production The database refuses
One token

Every check reads the same token

When a user signs in, their token carries who they are, their organisation and role, their plan and payment status, and what your flags target. Your API checks it in one guard, offline, and your UI reads the same answers.

Identitywho signed in, and howsub · amr
Rolesthe organisation and what it allowsorg.role
Billingthe plan and its payment statusbilling.plan
Flagswhat is switched on for this userflag()
In your code

Same SDK, your infrastructure

Every app and API works the same against a dedicated or on-premises deployment: only the domain changes.

Read the guide
api/auth.ts
// Your dedicated or on-premises deployment: the same SDK, your own domain
import { createAuth } from '@anchring/auth/server';

export const auth = createAuth({
  project: 'citizens',
  env: 'prod',
  domain: 'id.agency.example', // issuer: https://citizens.prod.id.agency.example
  audience: 'case-api',
});

app.use('/api/*', auth.middleware()); // verified on your servers, offline
The plan

Sovereign in numbers

Prices in euros, excluding VAT. Test environments include every feature on every plan.

Compare all plans
€20,000

and up a year, by agreement

Unlimited

monthly active users

Unlimited

enterprise SSO connections with SCIM

0

US processors in the chain

EU

law, hosting and contracting party

Questions

Before you start

Who runs the deployment?

We do, on EU infrastructure you approve. Or your own team does, on your premises, with our images, updates and support.

What does the agreement cover?

The DPA, the sub-processors, support terms and escrow, with Simon ApS in Denmark as the contracting party.

Can we start hosted and move later?

Yes. Start on the hosted service, then move to a dedicated or on-premises deployment. Your apps change only their domain.

Talk to us about Sovereign

Tell us about your requirements and your procurement.

Write to hello@anchr.ingSee pricing
We reply within one business day.
Who it's for

For developers

The Free plan

For startups

The Startup plan

For B2B SaaS

The Team plan

For agencies

The Team plan

For scale-ups

The Scale plan

For enterprise

The Enterprise plan

Compare all plans

Every plan side by side, and the questions people ask before paying.