Traditional identity systems stop at organisational boundaries. Here is what crosses them.
Standard identity tools were built for single organisations. Cross-institutional trust at scale requires a different foundation — the choice of Swiss healthcare.
Discuss this architecture for your organisation — no commitmentFour structural limitations of standard identity tools
OAuth (Open Authorization) and Public Key Infrastructure (PKI) are excellent tools — within a single organization's boundary. These are not failures. They are architectural constraints that become visible when trust needs to span organizations.
Token trust
OAuth / PKI constraint
OAuth tokens are trusted within the boundaries of their issuer. Across organisations, this 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 — every organisation's identity is verifiable by any other organisation without dependency on a shared certificate authority.
Access granularity
OAuth / PKI constraint
OAuth scopes are coarse — designed for application-level permissions. Resource-graph consent across organisational boundaries requires a different model.
DKMS / Verimesh solution
Verimesh's policy engine (Open Policy Agent, OPA) enables programmable, granular access control that operates across organisational trust boundaries.
Auditability
OAuth / PKI constraint
OAuth logs are organisational. Cross-organisational audit trails — who accessed what, when, authorised by whom — require cryptographic chaining that OAuth was not 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
OAuth / PKI constraint
OAuth assumes a central authority — an identity provider everyone trusts. Distributed institutional trust between sovereign organisations cannot depend on a single authority.
DKMS / Verimesh solution
DKMS enables sovereign identity management — every organisation controls its own cryptographic roots. Trust is established bilaterally, not delegated to a central coordinator.
OAuth for local tokens, DKMS for scalable institutional trust
This is an evolution, not a replacement. OAuth (Open Authorization) is the right tool for local authentication within the boundaries of a single organisation. DKMS (Decentralized Key Management System) is the right tool for institutional trust at scale — across sovereign organisations without a shared identity provider. Verimesh combines both, deploying each where it is the right tool.
Aligned with Switzerland's national eID programme
Swiyu is Switzerland's national electronic identity programme, currently under development. It is built on the same Self-Sovereign Identity (SSI) and decentralised trust model that underpins Verimesh and SEAL. This is not a coincidence — the same architectural principles that solve institutional trust at scale are now being adopted at the national level.
Vereign has been involved in the Swiyu consultation process from its earliest stages. Georg Greve served on the Swiyu Technical Advisory Council, contributing practical experience from production-scale DKMS deployment in Swiss healthcare. This direct involvement ensures that Vereign's architecture remains aligned with Switzerland's evolving regulatory and identity infrastructure.
For organizations deploying Verimesh today, Swiyu alignment means their trust infrastructure is future-proof with respect to Swiss regulatory direction. The architectural decisions are compatible — organizations are not building for today's requirements alone, but for the trust environment Switzerland is building towards.
Verimesh delivers this architecture
Verimesh (formerly the Stargate project) is the production implementation of the DKMS-based trust architecture described above. It combines OAuth for local authentication with KERI-anchored DKMS for cross-organizational trust, a programmable OPA-based policy engine, semantic interoperability via Overlays Capture Architecture (OCA), and verifiable communication via SEAL.
SEAL, the verifiable communication component of Verimesh, is already processing over 800,000 verified messages per month across Swiss healthcare. Full Verimesh deployment is in early production with HIN and rolling out throughout 2026, chosen by Swiss healthcare as the future trust fabric.
Explore VerimeshOne root, from the application down to the wire
The Verimesh mesh runs over WireGuard, and the tunnel key shares the same root as the application identity. 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 — the same protocol security vendors such as Palo Alto Networks recommend. 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 centralized identity.
DKMS satisfies five invariants 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.
After 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 verifiable communication component built on this trust architecture, already processes 800,000+ verified messages per month. Full Verimesh deployment with structured data exchange is in early production with HIN and rolling out throughout 2026.
800,000+
verified messages per month
850+
gateways across Swiss healthcare
30,000+
GP offices and healthcare institutions
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?
Book an architecture review — map this to your trust boundaries.
This architecture is deployed in Swiss healthcare at national scale. Whether you are evaluating alternatives to centralized identity or planning cross-organizational data exchange, we will map it to your environment in a 30-minute call.