One verifiable identity for your whole organisation.
Not just the company: every department, device, service and agent, verifiable by the institutions you work with, with no shared provider in the middle.
Discuss this architecture for your organisationFour structural limitations of standard identity tools
OpenID Connect, OAuth and Public Key Infrastructure (PKI) are excellent tools inside a single organisation's boundary. Federation does not remove that boundary, it moves it: either into agreements negotiated in advance between every pair of organisations, or into a central broker that none of them controls. These are not failures. They are architectural constraints that become visible the moment trust has to span organisations.
Token trust
Where standard tools stop
Access tokens are trusted inside the boundary of whoever issued them. Across organisations that boundary breaks: the receiving organisation has no way to verify the issuing organisation's authority.
DKMS / Verimesh solution
DKMS establishes cryptographic identity that is self-certifying: each organisation's identity is verifiable by any other organisation, without depending on a shared certificate authority.
Access granularity
Where standard tools stop
Scopes are coarse, designed for application-level permissions. Resource-graph-level consent across organisational boundaries requires a different model.
DKMS / Verimesh solution
Verimesh's policy engine (Open Policy Agent, OPA) enables programmable, fine-grained access control that operates across organisational trust boundaries.
Auditability
Where standard tools stop
Authentication logs stop at the organisation that wrote them. Cross-organisational audit trails, who accessed what, when, authorised by whom, require cryptographic linking that local authentication was never designed to provide.
DKMS / Verimesh solution
KERI (Key Event Receipt Infrastructure) provides tamper-evident audit trails. Every identity event is cryptographically linked and independently verifiable, creating cross-organisational auditability.
Trust architecture
Where standard tools stop
These models assume a central authority, an identity provider that everyone trusts. Distributed institutional trust between sovereign organisations cannot depend on any single authority.
DKMS / Verimesh solution
DKMS enables sovereign identity management: each organisation controls its own cryptographic roots. Trust is established bilaterally, not delegated to a central coordinator.
Keep your identity provider. Add trust between institutions.
This is a new capability. Your identity provider, and the protocols behind it (OpenID Connect, OAuth, SAML), are proven for authentication inside a single organisation, and they stay where they are. DKMS (Decentralized Key Management System) does what they were never built for: it gives each organisation a self-certifying identity that any other institution can verify directly, without a shared provider between them. Verimesh delivers DKMS and speaks to the systems you already run, so you extend what you have instead of migrating off it.
Building on national eID programmes
The swiyu programme is Switzerland's federal electronic identity infrastructure. Its first credential, the electronic learner driver permit, has been live in all cantons since December 2025, with around 27,000 issued. Commissioning of the e-ID trust infrastructure is targeted for the first half of 2027, while introduction of the e-ID itself has been postponed with no new date announced. Issuer identifiers and trust statements are published in central federal registries, and the credential is held on the citizen's own device. The same infrastructure is expected to carry credentials from cantons, universities and employers once it opens to general issuers.
Vereign has been involved in the Swiss e-ID process from the start, through participation meetings and bilateral exchanges, and Georg Greve was a member of the Technical Advisory Circle, which fedpol convened and whose conclusions informed the January 2024 technology decision.
The European Union is on the same path. Regulation (EU) 2024/1183 requires every member state to provide at least one European Digital Identity (EUDI) Wallet, and the foundational person credential comes from state-designated providers. Both programmes answer the same question, and answer it well: how a person proves who they are to an institution. Neither specifies identity for the departments, devices, services and agents an organisation actually runs, and both anchor trust in central registries, which is why neither keeps a register of the relying parties that verify credentials: at Union scale there would be far too many to list.
For organisations deploying Verimesh, swiyu and EUDI become inputs you can build on. The bridge is designed rather than shipped today: once those systems reach production, you accept a state e-ID at onboarding, use it as a root of trust, and let Verimesh carry that trust across the institutions, jurisdictions and systems a real workflow touches, issuing your own credentials back into the same wallet.
Verimesh delivers this architecture
Verimesh (formerly the Stargate project) is the production implementation of the trust architecture described above. It works with the authentication you already run and adds what that layer was never built to do: DKMS-rooted organisational identity for trust between institutions, a programmable policy engine (Open Policy Agent), shared data meaning through Overlays Capture Architecture (OCA), and tamper-evident message delivery through SEAL.
Verimesh is in production in Swiss healthcare. The gateway and central CA at HIN run in production, the first institutions are migrated and using them, and migration across the HIN network is planned to complete before the end of 2026.
Explore VerimeshOne organisational identity, down to the network layer.
Verimesh carries its traffic over WireGuard, and the tunnel key is rooted in the same organisational identity as the applications above it. Each organisation's Curve25519 tunnel keys are derived from its own Decentralized Key Management (DKMS) material: no central authority issues them, and there is no gap between network-layer and application-layer identity. Key rotation is coordinated with DKMS (pre-rotation built on KERI), and every tunnel establishment is auditable against the key event log. No intermediary owns the data flow.
Silent by design
Unauthenticated packets get no reply. The mesh is invisible to a port scan: there is no public attack surface to probe.
About 4,000 lines you can read
WireGuard is roughly 4,000 lines of code, against about 100,000 for OpenVPN and 400,000 for IPsec. Auditability is itself a security property.
No negotiation, no downgrade
Fixed modern primitives: Curve25519, ChaCha20-Poly1305, BLAKE2s, the Noise_IKpsk2 handshake. Perfect forward secrecy with roughly two-minute rekeying and identity hiding are built in, not configured.
Sovereign to the wire
Open Source end to end, self-hosted, with no SaaS control plane in the path. Sovereignty extends from the application down to the transport itself.
Boring, proven infrastructure
In the mainline Linux kernel since 2020. Nothing here is novel cryptography, and it carries the Verimesh rollout with HIN today.
Ready for the quantum migration
WireGuard's pre-shared-key layer already hedges today's traffic against store-now, decrypt-later attacks. And because tunnel keys derive from DKMS, moving to post-quantum algorithms is a routine key rotation on the existing key event log, not a big-bang reissuance.
Consent enforcement is what DKMS is for
EHDS Article 71(8) creates a structural constraint that no central authority can satisfy: when a person opts out of secondary use, that withdrawal must propagate across every institution that holds or derives data from the original. No CA can co-sign the opt-out; no identity provider can cascade the revocation. The constraint is architecturally incompatible with centralised identity.
DKMS satisfies five requirements EHDS Article 71 requires: person-scoped identifiers that survive re-enrollment; verifiable, timestamped opt-out records anchored in the Key Event Log; reversibility without re-identification; cross-controller propagation without bilateral agreements between every institution pair; and unlinkability between the consent record and the data it covers.
Once data has been disclosed (shared across a hospital network, a research consortium, or a payer chain), a subsequent opt-out must still reach every downstream controller. DKMS key event logs propagate the revocation cryptographically: each controller's KEL is append-only and witnessed, so a revocation appended at the person's edge becomes verifiable at every institution that holds a derived record.
Read the consent architecture thesisProven in Swiss healthcare, chosen for national-scale deployment
HIN (Health Info Net) is Switzerland's health information network, connecting hospitals, GP practices, and specialist providers across cantonal boundaries. SEAL, the entry product on this trust layer, already carries more than 800,000 verified deliveries per month. Verimesh is in production in Swiss healthcare: the gateway and central CA at HIN run in production, the first institutions are migrated and using them, and migration across the HIN network is planned to complete before the end of 2026.
800,000+
verified deliveries per month
Trust Architecture: frequently asked questions
What is DKMS?
How is DKMS different from PKI?
Does DKMS replace OAuth?
Is DKMS post-quantum ready?
Who maintains DKMS?
Does DKMS require a blockchain?
Can Vereign help me integrate with the swiyu or EUDI wallet?
Is Vereign a competitor to national wallets?
Is the Verimesh bridge to swiyu or EUDI in production?
Book an architecture review. We map this to your trust boundaries.
This architecture is deployed in Swiss healthcare at national scale. Whether you are evaluating alternatives to centralised identity or planning cross-organisational data exchange, we will map it to your environment in a 30-minute call.