Swiss e-ID Audit 2026 Review: Where Trust Hits the Road
What this is about
The Swiss Federal Audit Office (SFAO) has conducted its second audit of the Swiss e-ID program (dated December 19, 2025 and published on February 18, 2026). It is worth reading whether you work in digital identity or are simply curious how Switzerland’s new government-issued e-ID may hold up once technical architecture meets societal reality (e-ID Audit).
Why this may be worth reading
This blog article reviews four selected audit points across stages that are introduced here to show where trust is tested in everyday interactions: from when someone asks you for your data, how that data is protected, and what keeps verification of that data available, to who gets to participate - at what cost of openness.
Along the way, this article applies a self-sovereign identity (SSI) lens, and uses three additional reference points to surface angles the audit does not cover directly: myTerms (how requests could become clearer at the moment data is asked for), Bring Your Own Identifier (BYOI) (how operational chokepoints can form even with modern identifier building blocks), and First Person Project (what accountability could look like when AI agents increase activity at scale).
The point of this article is not to propose replacements, but to keep one question open: Who should hold agency, decision power, and accountability in the e-ID ecosystem?
The article has the following structure. It begins with background on the e-ID infrastructure, the overall program, and the audit itself. It then clarifies self-sovereign identity as a lens for interpretation before moving through four stages where institutional design meets practical reality. Each stage follows the same pattern: what the audit says and suggests, a broader perspective to contextualize it, and a set of reflections to invite further discussion.
How to read this
Jump to where you like to be (read)
Click on the bold text of your interest
or, just keep scrolling
Background – getting started |
-> FOJ, FOITT, fedpol | Issuers, holders, verifiers, registries | e-ID program & audit in a nutshell |
A word that matters: “self-sovereign”-> SSI clarification | "State-not-in-the-loop" vs. individual control | SSI-style building blocks |
Stage I – When someone asks you for your data-> Trust Registry & Trust Statements | Legitimate verification purposes | Pre-registered data fields | Wallet visibility of purpose | Purpose binding in transactions |
Stage I – Let's zoom out-> Registry logic vs. user decision-making | Meaningful consent in the moment | Self-Sovereign Identity perspective | myTerms as negotiable request framing |
Stage I – Food for thought
Stage II – How the data you show is protected-> Transport encryption | End-to-end payload encryption | Incomplete payload concept at audit time | DevSecOps application | Security vs. delivery schedule |
Stage II – Let's zoom out-> Authenticity vs. confidentiality | Exposure through infrastructure layers | Security as architectural property | Operational maturity before launch |
Stage II – Food for thought
Stage III – What keeps verification of your data available-> Issuer submission to the Base Registry | "chained list of published keys" | Credential status lists | Username/password access controls | Risk of deletion attack |
Stage III – Let's zoom out-> Availability vs. forgery risk | Operational concentration | Registry dependency for verification | SSI perspective on decentralization |
Stage III – Food for thought
Stage IV – Who gets to participate – and at what cost-> Base Registry participation model | Limited registration fields | Limited participant data controls | Program answer | No formal audit recommendation |
Stage IV – Let's zoom out-> Openness vs. governability | Human navigation of registries | AI-driven registration at scale | Accountability by design discussion |
Stage IV – Food for thought
Background
The Swiss e-ID Trust Infrastructure at a Glance
The diagram below illustrates the official architecture of the Swiss e-ID trust infrastructure as presented by the program. It shows the relationship between issuers, holders, verifiers, registries, and the trust infrastructure.
Diagram of the Swiss e-ID trust infrastructure and components. Source: Swiss Federal e-ID Program, eid.admin.ch/technology (accessed Feb. 25, 2026)
In the following, “government-operated” refers to the division of roles: FOJ is responsible for the legal and program mandate, FOITT builds and operates the trust infrastructure, and fedpol issues the e-ID. This serves as a structural reference point for the four moments of trust discussed below.
e-ID Audit and Program - in a nutshell
-
The responsible authorities of the e-ID program are the Federal Office of Justice (FOJ), the Federal Office of Police (fedpol), and the Federal Office of Information Technology, Systems and Telecommunication (FOITT).
The trust infrastructure of the e-ID is designed as an open platform that can also integrate other verifiable credentials. Around CHF 182 million were approved for development and pilot projects, with expected annual operating costs around CHF 25 million. A public beta of the e-ID and the swiyu wallet has been running since March 2025, and the earliest possible go-live launch is currently planned for Q3 2026.
-
The e-ID audit assesses the projects “e-ID issuance” and “trust infrastructure,” as well as the technical IT security design of the Swiss e-ID.
The audit report is clear: many key tasks remain open, and the stabilization phase at the end of the program must not become a buffer for unfinished work. If necessary, launch should be postponed in favor of product maturity. However, it does not suggest that the Swiss e-ID is broken. It suggests that it is moving from theory into practice, and that practice exposes where assumptions need reinforcement.
-
The audit’s wording (“Basic Register,” “Trust Register”) is kept in quotes when referenced directly. Elsewhere, this article uses “Base Registry” and “Trust Registry” to match registry terminology in digital trust infrastructure discussions.cription
A word that matters: “self-sovereign”
The report describes parts of the architecture as “self-sovereign” (“selbst-souverän”) because the state does not participate in transactions between holder and verifier (the exchange happens directly between holder and verifier), and, it extends that framing to participating companies and organizations (e-ID Audit Report (German) p. 16).
That “state-not-in-the-loop” property can reduce state visibility into individual transactions. But in the broader Self-Sovereign Identity (SSI) discourse, “self-sovereignty” is neither about the state nor about companies or organizations. It’s about the individual. SSI (as articulated by early principles) is fundamentally about ensuring the individual’s control over their identity and data, which includes for example, minimal disclosure, portability, and resilience under power asymmetries (see Christopher Allen’s early SSI principles, 2016). “State-not-in-the-loop” is not the same as “self-sovereignty”.
The Swiss e-ID is therefore best understood as centrally, government-operated infrastructure that uses some SSI-style building blocks. That is not a critique. It is a clarification – and it becomes relevant the moment someone asks you for your data.
Stage I
When someone asks you for your data
(Verifier purpose legitimacy – report 2.1 Ohne überprüfte Verifikationszwecke leidet die Vertrauensfähigkeit)What the report says
The Trust Registry allows issuers and verifiers to voluntarily undergo deeper identity checks by the Federal Office of Justice (FOJ) and receive a corresponding Trust Statement. This makes it possible to verify who stands behind a registered identifier.
Beyond this identity verification, the legal and technical framework also provides for the possibility of verifying the legitimate purposes for which a verifier may check the e-ID (“legitime Abfragezwecke”). However, the e-ID program currently does not plan to use this type of Trust Statement for verified purposes in e-ID transactions.
In other words, (under current plans) verifiers can request e-ID data without a structured, wallet-visible mechanism that indicates whether the requested data fields of an e-ID correspond to a pre-declared and reviewed legitimate purpose. The wallet may signal that an issuer or a verifier has undergone identity checks, but it does not bind a live request to a government-reviewed statement of purpose.
What the report suggests
The SFAO considers it important that the Trust Registry indicates which purposes for requesting specific data fields of the e-ID are legitimate. It therefore recommends that the program introduce and apply a voluntary process under which verifiers can register the data fields they intend to request, together with a mechanism for checking the corresponding positive Trust Registry entries for verified purposes in e-ID transactions.
Let’s zoom out - what this review says & suggests
The audit report focuses on clarifying what is being requested, for which purpose, and whether that purpose has been voluntarily declared and reviewed. The approach suggested in the report is pragmatic: allow verifiers to pre-register intended data fields, and let the wallet visualize whether the live request aligns with that pre-registration. That increases transparency and reduces unpleasant surprises for e-ID holders at the moment the e-ID is requested.
But there is a subtle governance shift hiding inside the convenience: trust risks being delegated to registry logic – “this request is fine because the system says so”. An SSI-informed lens puts the pressure elsewhere. The core question then is whether a person can make a meaningful decision in the moment: do they understand why the data is needed, what happens if they refuse, and whether less data would suffice?
Registry indication can support informed decision-making – but it should not replace it
This is where approaches such as myTerms are interesting as a design direction. Rather than trying to “make the world safe” by pre-verifying verifier requests, they aim to make conditions explicit and negotiable. That shifts the interaction from a binary accept/reject toward expressing boundaries: what a person is willing to share, under which conditions, and with what limits.
note: myTerms (and similar approaches) are not part of the e-ID program and not audit recommendations; they are used here only as illustrative examples of alternative design directions that make the conditions and purpose of a data request clearer and negotiable at the moment a person is asked to share data.
Food for Thought
The audit does not go as far as suggesting approaches such as myTerms, and people can disagree on how much should be handled by public registries versus personal choice in the moment.
But the design question is worth keeping visible: should trust rely mainly on what the system has checked in advance, or on helping people understand and decide when they are asked to share data?
The Swiss e-ID registries - in a nutshell
-
The e-ID trust infrastructure is structured around two core registries: the Base Registry, which includes registered identifiers of participants (DID Docs for issuers and verifiers) as well as status lists for issuers; the Trust Registry, which includes Trust Statements for participants who voluntarily undergo deeper checks by the Federal Office of Justice (FOJ).
-
Issuers and verifiers have to register their identifiers in the Base Registry, and in addition, may voluntarily apply for a Trust Statement in the Trust Registry. If granted, this positive entry is displayed in the swiyu wallet during a transaction, showing that the counterparty has successfully undergone additional verification by the government.
Stage II
How the data you show is protected
(Payload encryption – report 3.1.a Die Verschlüsselung der Nutzdaten ist noch nicht fertig konzipiert und integriert)What the report says
The communication channels between participants of the e-ID ecosystem are encrypted using standard methods. For example, when a person uses the swiyu wallet to share selected e-ID data with a verifier (such as a bank, an employer, or a public authority), the exchange between the wallet and the verifier’s system is sent over an encrypted connection.
It adds that transport encryption is not always sufficient against unknown attackers, because traffic can traverse infrastructure and routing paths that are neither fully transparent nor inherently trustworthy to the parties involved. In the program design, transport encryption is meant to be complemented by end-to-end encryption of the transferred e-ID data (the payload), so that only the intended endpoints can read it – a step that is explicitly welcomed in the report.
However, the SFAO notes – with some surprise – that the concept for payload encryption was still incomplete at the time of the review, and that implementation in the trust infrastructure was pending. According to the program’s planning documents referenced in the report, the missing payload-encryption functionality was scheduled for completion by the end of 2025. Separately, the report states that, at this specific point, the DevSecOps approach was not applied consistently.
What the report suggests
Although the report does not include a separate recommendation for this subsection, its position is clear in context. It welcomes the planned introduction of end-to-end encryption, and at the same time makes clear that key security components should not remain open late in the project lifecycle.
More broadly, the SFAO emphasizes that security and stability must take precedence over schedule pressure. The stabilization phase at the end of the program is not intended to compensate for unfinished development work. If necessary, the planned launch should be postponed in favor of product maturity.
Let’s zoom out - what this review says & suggests
In wallet-based credential flows, payload data is not random. It is signed, meaningful information that verifiers rely on. Signing makes data verifiable, which is why this data is valuable. But signatures provide integrity and authenticity, not confidentiality. If payload encryption is not fully integrated, confidentiality depends on surrounding infrastructure decisions: routing layers, logging practices, and integration patterns. That is where exposure can occur, even without active tampering.
The DevSecOps remark (the audit mentioning the DevSecOps approach was not applied consistently by the e-ID program) should therefore not be read as a minor aside. It points to delivery maturity: whether security work is carried consistently across teams and timelines.
The deeper question is whether security is treated as a foundational property of the system
or as a milestone to be completed before launch. Encryption that arrives late risks being layered on; encryption designed early shapes architecture.
note: in its formal response published in the report, the FOITT states that DevSecOps is part of its standard way of working and is applied consistently.
Food for Thought
The audit does not claim the system is insecure by design. It points to timing and integration gaps, and people can disagree on what “ready enough” looks like before launch.
But the design question is worth keeping visible: when does planned security become security in practice — and how much maturity should government-operated digital identity infrastructure demonstrate before it moves from pilot to everyday use?
Stage III
What keeps verification of your data available
(Issuer technical access controls – report 3.2 Technische Zugriffe der Ausstellerinnen sind nur schwach gesichert)What the report says
Issuers periodically submit essential information to the Base Registry, including a “cryptographically chained list of published keys” (i.e., the verification key material that verifiers resolve, typically via a DID document) and a signed list indicating credential status (used to check whether a credential has been revoked). Verifiers rely on this information to decide whether a credential presented by a holder should be accepted.
Access for issuers to upload this information is currently secured via username and password. For a system intended to underpin a public digital identity infrastructure, operated by the government, the SFAO considers this level of protection outdated.
The report notes that if such access credentials were compromised, a deletion attack on the trust infrastructure could become possible. In other words, key material or revocation data required for verification could be removed. In that case, verification would not necessarily be falsified, but it could become unreliable due to loss of availability or accessibility.
What the report suggests
The SFAO recommends introducing stronger, individualized authentication mechanisms — for example certificate-based access or API keys — and ensuring that issuers can immediately block access if misuse is suspected.
Let’s zoom out - what this review says & suggests
Even if someone gained unauthorized access to the artifacts, the artifacts delivered to the Base Registry are cryptographically signed. That makes forgery unlikely, because an attacker would still need the corresponding private keys – a different class of risk, including how securely private keys are protected by issuers and verifiers.
But you do not need to forge credentials to disrupt a system if you can delete or temporarily disable access to the data that verification depends on. Hence, the concern here is mainly availability: if public keys or status information become unavailable, verification can quickly become brittle.
In this context the audit explicitly focuses on issuer submission access. However, the structural dependency goes further. In the current architecture, verifiers likewise register their DID documents in the Base Registry. If that material becomes unavailable, resolution and verification flows can equally be disrupted. The risk is therefore not limited to issuers; it concerns the availability of data stored in the registry as a whole.
This also reveals a structural dimension. Similar “delete or disable” effects do not necessarily require an external attacker. In centrally operated infrastructure, privileged operational access – or operational failure – can have the same consequences. In other words, central coordination can simplify governance and incident response, but it also concentrates operational control.
Even when using decentralized building blocks such as DIDs and Verifiable Credentials, the core of the e-ID trust infrastructure remains dependent on central operational integrity and availability
From an SSI perspective, decentralization is also about avoiding gatekeepers: users keep control, access, and portability, rather than being locked into a single operator or access path. One practical way this shows up in architecture is the idea of Bring Your Own Identifier (BYOI), as for example explained here and here.
In summary, even if participants control their own keys, verification can still end up relying on centrally operated publishing and update paths for critical material (such as DID documents or status information). Viewed through that lens, BYOI-style patterns point toward distributing where identifiers “live” and how key lifecycle is managed, which can reduce reliance on single operational chokepoints.
Utah’s SEDI model is often referenced as an example for applying this pattern in some digital identity discussions: individuals control identifiers first, while credentials are endorsed on top of those identifiers, with delegation treated as a core capability.
note: BYOI and SEDI are not part of the e-ID infrastructure and not audit recommendations; they are used here only as reference points when thinking about resilience and the concentration of operational dependencies.
Food for Thought
The audit does not question central operation as such, nor does it argue for a different architectural model. It identifies a specific access control weakness and recommends strengthening it.
But the design question is worth keeping visible: how much operational concentration is acceptable in a system that underpins public digital identity, and how resilient should verification remain if one central component fails or is misused?
Stage IV
Who gets to participate – and at what cost of openness
(Base Registry: no regular controls of participant data – report 3.3.c Im Basisregister sind keine regelmässigen Kontrollen der Teilnehmerdaten vorgesehen)What the report says
The audit distinguishes between the Base Registry and the Trust Registry. Participants who wish to appear in the Trust Registry undergo a voluntary verification process. By contrast, the Base Registry — which contains all registered participants — does not include planned regular controls of participant data.
Registration in the Base Registry requires only a limited set of mandatory fields. The submitted data is not systematically validated, and access to the infrastructure can be used once registration is completed and any applicable fees are paid.
The program’s reasoning, as recorded by the audit, is that participant data stored in the Base Registry is not used elsewhere in the system. Verification requests include information about the sending party within the transaction itself, and the trust infrastructure is not queried for that purpose.
What the report suggests
The SFAO does not provide a formal recommendation for this sub-section. Instead, it records the current design choice and the program’s justification. The question of whether additional controls are necessary is left open within the documented architecture.
Let’s zoom out - what this review says & suggests
This is an openness trade-off. Lower barriers encourage participation and ecosystem growth, but they also mean that registry presence should not be mistaken for trustworthiness (in the human sense). That said, openness has advantages: “permissionless” (in the sense of registration without prior approval) keeps the infrastructure broadly accessible and avoids turning basic participation into a gated privilege. But openness does not remove responsibility; it relocates it. If entry is unrestricted, the surrounding governance and usability design must absorb the complexity.
Technical systems are not only secured; they are navigated. People skim names, rely on patterns, and make decisions in a rush. If registries contain misleading, confusing, or low-quality entries, the burden shifts to user interface design, monitoring processes, moderation mechanisms, and operational oversight.
The challenge is therefore not simply openness, but governability at scale
And “at scale” is not only about more humans using the system — it is also about AI agents.
AI agents don’t introduce entirely new forms of identity misuse, but they can dramatically change the dynamics: speed, volume, and variation at scale. Rapid re-registration and small mutations can quickly overwhelm usability and operational oversight. The question becomes less about isolated malicious entries and more about attention: how much attention can users and operators realistically allocate to sorting relevant information from chatter (or signal from noise)?
As activity scales, the pressure shifts from “who is registered?” to “who is behind an action?” The First Person Project (FPP) explores an approach that combines proof of a real, unique person (proof of personhood) with verifiable trust relationships—and extends this foundation toward tools that help individuals safely delegate to personal AI agents. This is not referenced in the audit and not part of the Swiss e-ID program, but it illustrates one direction for keeping openness governable without drifting into blanket gatekeeping.
note: FPP (and similar approaches) are not part of the e-ID program and not audit recommendations; they are referenced here only as examples of how openness could remain usable under AI-scale conditions.
Food for Thought
The audit does not treat openness in the Base Registry as a mistake, and it does not call for closing it down. It documents a deliberate design choice and the program’s rationale. People can disagree on where the right balance sits between low barriers and ongoing oversight.
But the design question is worth keeping visible: what does an open trust infrastructure need — in user-facing cues, operational safeguards, monitoring, and accountability — to remain workable as it scales, considering AI agents can drive high-volume registration, rapid churn, and targeted confusion?
Phone * Take-home
The interesting part starts where architecture meets daily use. If you are involved in digital identity – as a builder, operator, issuer, verifier, or someone affected by it – treat the audit as an invitation to tighten what needs tightening before scale sets the defaults.
This review is meant as a practical reference: a structured walk-through of four pressure points, with additional lenses to expand what the audit covers and to surface design questions that may otherwise stay implicit, or not asked.
If you disagree with my framing, even better — use the comment section below to challenge it and push the discussion forward, or reach out directly.
*one nerdy joke slipped through 🤷🏽♀️If you’d like to support independent writing like this, you are very welcome to do so here
Change History
Feb 25, 2026, finalizedFeb 27, 2026 Adapted som titles to make clearer where the official audit ends and the review of that audit - what this article is about - starts; increased font contrast