What the federal government actually announced
The postponement was announced on 30 June 2026. The Federal Office of Justice attributed it to additional security work required by new AI capabilities. The online issuance process is to receive better protection against malware injected into end-user devices and against deepfakes. The federal government intends to give a precise launch date once the work is largely complete. The separate trust infrastructure is expected to start operating in the first half of 2027. It is intended to support other electronic credentials independently of the E-ID. This timeframe is therefore not a committed launch date for the E-ID (Federal Office of Justice, 30 June 2026).
The communication of 3 September 2026 reaffirms this approach. In connection with the Digital Switzerland Advisory Board, the federal government explains the security work and refers to open source, penetration testing and bug bounty programmes. It should be read as confirmation and explanation of the previously announced postponement. The communication reports neither a successful attack on the E-ID nor a data leak (Federal government communication, 3 September 2026).
For project planning, businesses should distinguish between technical testing, production operation of the trust infrastructure and the availability of a state-issued E-ID. Combining these stages into a single launch date creates avoidable dependencies.
Why identity verification must go beyond the video image
Several elements must align in digital identification: the evidence presented must be authentic, belong to the person presenting it and be verified through a reliable process. A deepfake can falsify a person’s visible appearance. In an injection attack, manipulated image or video material is introduced between capture and the verifying party.
The US technical agency NIST expressly addresses these risks in its digital identity proofing guidelines. It states that biometric comparison alone does not prevent such attacks. Methods for detecting the presence of a real person, often termed “liveness detection”, do not cover every attack variant either. The guidelines provide technical guidance; they do not create an independent statutory obligation for Swiss businesses (NIST SP 800-63A-4, section 3.14).
From an advisory perspective, the entire process should therefore be reviewed. This includes the origin of image data, the integrity of the components used and the handling of anomalies. Manual escalation should enable additional, independent checks. If an employee merely reviews the same manipulated video again, the original weakness remains.
The business perspective is equally important: an incorrect identity decision may grant access to an account, confidential information or a service of financial value. The required level of security should reflect these consequences.
What this means for banks and financial intermediaries
The E-ID is also intended to support the digital establishment of customer relationships. On 16 December 2025, FINMA opened a consultation on a partial revision of Circular 2016/7 “Video and online identification”; the consultation closed on 27 February 2026. The project aims to include the state-issued E-ID as a means of digital identification compliant with the Anti-Money Laundering Act. For any implementation, the final rules and their entry into force must be checked separately (FINMA, consultation of 16 December 2025).
Identification is one part of due diligence. Other requirements include establishing the beneficial owner, investigating higher risks and implementing suitable organisational measures. Successful proof of identity does not resolve those further questions. For corporate customers, it must also be established whether the identified person is authorised to act for the company (FINMA, duties of financial intermediaries).
The federal communication of 3 September does not itself create any additional FINMA obligation. It does, however, provide a substantive reason to assess existing processes against the changing risk landscape. Institutions with E-ID-dependent projects should keep permissible alternative identification methods operational and secure their capacity for the transitional period.
Traceability also deserves attention: which checks were performed? Which warning signs were present? Who approved an exception? It should be possible to reconstruct this information from the documentation. A result field simply stating “Identification successful” may provide too little information for internal control and incident investigation.
Biometric security requires deliberate data architecture
Additional fraud detection may generate additional personal data: video recordings, technical device information, facial features or risk scores. Under Swiss data protection law, biometric data that uniquely identify a natural person are sensitive personal data. Classification depends on the specific processing; an ordinary photograph is not equivalent to biometric identification merely because of its visual content.
Under Article 7 FADP, data protection by design and by default must be incorporated at the planning stage. For identification processes, raw recordings, derived features and the necessary verification evidence should therefore be considered separately. The purpose, access permissions and retention period should be defined for each category, taking account of statutory documentation duties. Blanket retention of all data “for security” is too imprecise a justification (FDPIC, sensitive data and data protection by design).
Where planned processing may create a high risk to personality or fundamental rights, Article 22 FADP generally requires a prior data protection impact assessment. Relevant factors include the technology, scale, circumstances and purpose. The use of AI does not therefore automatically require a DPIA in every case. For large-scale biometric identification, however, the risk assessment must be particularly thorough. An existing impact assessment should be reviewed when material changes occur (FDPIC, data protection impact assessment).
Implementation includes providing understandable information at the right time. Before collection, customers should be able to identify who processes their data, for what purposes and to whom it is disclosed. In practice, a short notice within the identification process, with easily accessible further information, is useful (FDPIC, duty to provide information).
The E-ID also offers opportunities for data minimisation. For example, the federal government envisages that proof of age may disclose only whether the required minimum age has been reached. Businesses should therefore design data requests around the specific business need: proof of age and customer identification under banking law require different information (Federal government, E-ID operation and data protection).
What belongs in the contract with the identification provider
Many businesses obtain identity verification as an external service. Data protection responsibility remains with the commissioning company insofar as it is the controller. Under Article 9 FADP, particular attention must be paid to permitted processing, data security and authorisation of subprocessors. It must also be checked whether statutory or contractual confidentiality duties prevent outsourcing (FDPIC, processing by processors).
These requirements and the technical risks give rise to five specific areas to review when drafting contracts:
- Services and evidence: the contract should specify which identification steps the provider performs and which remain with the business. Verifiable tests against deception methods relevant to the intended use, together with figures for false acceptance and false rejection, are useful. General claims such as “AI-powered security” do not replace a testable service specification.
- Changes and security weaknesses: material changes to verification methods, models or interfaces should be notified and their effects capable of assessment. Identified weaknesses require specific remediation deadlines and a procedure for temporarily switching to additional controls.
- Data and purposes: permitted data categories, retention, deletion and assistance with data subject rights must be regulated. Use of customer data to train the provider’s own models should be excluded or separately assessed in advance from a legal perspective and expressly regulated.
- Incidents and cooperation: the provider should report anomalies and security incidents in good time, preserve relevant evidence and cooperate in investigations. Agreed notification periods must allow the business to fulfil its own investigation duties and any reporting obligations.
- Oversight and switching provider: audit reports and appropriate audit rights should enable oversight. The end of the contract requires a workable transition: available verification evidence, migration assistance and documented deletion in accordance with contractual and statutory retention obligations.
For cloud services, it must also be transparent where data are processed and which subprocessors are involved. Disclosures abroad require a separate assessment of the level of data protection and necessary safeguards. The location stated in the main contract is often insufficient as the sole basis for a decision. Regulated institutions must also consider the applicable supervisory requirements for outsourcing (FDPIC, data processing in the cloud).
How businesses can use the additional time effectively
Technical preparation can continue. On 4 September 2026, the E-ID programme announced that the existing public beta would become a sandbox. A dedicated “swiyu Sandbox Wallet” will be provided for this test environment; the regular wallet is intended to work with the production infrastructure in future. Organisations can therefore continue testing their own use cases (E-ID programme, 4 September 2026).
Businesses with specific E-ID projects should undertake a joint assessment by the business unit, IT security, data protection and legal teams within 30 days. This period is a practical recommendation, not a new statutory requirement. The outcome should record which projects depend on the E-ID launch, which alternatives are available and which technical or contractual gaps must be closed before implementation.
SMEs benefit from focusing on the essential transactions: where is identity actually needed? What service is subsequently released? What harm could deception cause? Appropriate controls can be derived from these questions without equipping every customer portal with comprehensive identity verification.
A sound implementation decision ultimately brings together four conditions: the legal requirements are clear, technical testing is meaningful, responsibilities are assigned and a fallback process works. This work improves digital customer onboarding today. At the same time, it creates the basis for using the E-ID in a targeted way, with demonstrable benefits, once it becomes available.