Digital Guest Identity: What e-ID, Registration, and Access Codes Prove

A successful digital identity check should never trigger a door code on its own. The result may confirm a person's identity or one attribute, but it does not show that the local registration procedure is finished. It also does not establish that the person arriving is part of the reservation or has permission to enter this unit during this particular period.

Six statuses make those gaps visible: the proof is technically valid, the identity matches, the registration details are complete, the official filing has been made, the stay is authorized, and access is active. A guest might upload digital proof before arrival and provide a name and date of birth that match the booking. At that point, some of the six conditions may be met while the rest remain open.

In professional accommodation, these statuses support four separate decisions: establishing identity, completing statutory registration, approving the stay, and granting physical access. Digital evidence helps only if the operation can tell which decision it supports.

Identity, registration, approval, and entry answer different questions

An identity check connects a person with a piece of evidence. Depending on the method, it may also verify an attribute such as legal age. Statutory guest registration has another purpose: it sends the information required by law to the competent authority. The operator must then approve the stay by checking the person against the reservation, resolving any exception, and confirming the required steps. A lock or access system then implements the decision, perhaps by issuing a code that works only for a set period.

Calling all four outcomes “verified” hides unfinished work. Airbnb may have checked the account holder while the local registration form is still incomplete. A future Swiss e-ID may make identity data available electronically, yet the federal government's official FAQ is explicit that it is not a travel document. A valid passport, for its part, gives its holder no right to enter a specific rental property.

Status labels should say exactly what has occurred: proof technically valid, identity matched, registration data complete, official filing completed, stay authorized, access active. Each needs a defined purpose and a person or role responsible for it.

Example: Identity Confirmed, Booking Assignment Still Unresolved

A company has booked an apartment for an employee. The employee passes the identity check, but the stay record still names the person who made the booking. This editorial example illustrates an unresolved assignment; it is not a product demonstration or customer case.

• Established: The verification result concerns the employee who will arrive.
• Still open: The responsible person must confirm and record whether that employee is the intended occupant. A matching company name alone does not settle the question.
• Separate work: Required registration details, any filing, and the operator’s access approval retain their own status.

Keep the exception visible until it is resolved. Name the person responsible for the next step and give the guest a contact route. A positive identity result does not automatically authorize entry.

What the EU Wallet and Swiss e-ID can support in 2026

Regulation (EU) 2024/1183 provides the European legal framework. The European Digital Identity Wallet is intended to let citizens, residents, and businesses use identity data and electronic attestations of attributes under controlled conditions. The European Commission treats selective disclosure as a central principle: a service should receive only the information it needs. In practice, a person could confirm legal age without handing over an image of the entire document.

The Commission expects member states to offer wallets by the end of 2026. That common target does not mean that every form of evidence, national wallet, or hotel connection will be ready on the same day. An accommodation provider still needs to know which wallet it supports, who issued the evidence, whether the evidence can be checked technically, and whether it is legally suitable for the intended use.

Switzerland has its own statute and schedule. The government e-ID received political approval in the 2025 referendum. On June 30, 2026, the Federal Office of Justice reported a delay to the e-ID launch and gave no new binding launch date. According to that announcement, the trust infrastructure is expected to be capable of starting operations in the first half of 2027.

A host cannot build today's check-in on the assumption that every guest carries an EU Wallet or a Swiss e-ID. A comparable manual or assisted route is still needed. Once either system is available, the operator will also have to decide whether its evidence is sufficient for the exact purpose in question.

Switzerland still requires a separate guest-registration procedure

Under Article 16 of the Foreign Nationals and Integration Act, a person who accommodates foreign guests in Switzerland for payment must report them to the responsible cantonal authority. The present federal procedure in Article 18 of the applicable ordinance calls for a registration form prepared from the identity document, signed by the guest, and transmitted to the competent authority. Cantons and municipalities determine how this is carried out and may request additional details for tourism purposes.

The Federal Council opened consultation on a digitization proposal on August 26, 2026. Under the proposal, an accommodation provider could submit the data electronically without the guest's signature after comparing the information with the identity document presented. As of September 10, 2026, the proposed amendment has not become law.

A future e-ID might help with that comparison, but it would not file the registration on its own. The operator still needs to determine who must be reported, which details the location asks for, when the report is due, and how completion is recorded. Visitor tax must be handled separately as well. The guide to guest registration in Switzerland examines those local requirements more closely.

Before issuing a code, check the stay itself

For self-check-in, it may seem efficient to connect “identity verified” directly to “send code.” The shortcut is too broad. Entry is permission for a defined place, period, and purpose. The booking, unit, and dates must at least agree. Depending on the operator's rules, payment, a deposit, occupancy limits, house rules, local registration, or a manually approved exception may also be relevant.

Conflicts between the name, reservation, and evidence should go to a person for review. Manual handling is also needed when someone else arrives, the document type is unsupported, or the system cannot read the evidence. The procedure must identify who makes the decision, what further information may properly be requested, and how a guest arriving late can obtain assistance.

The technical design can support this separation. The identity service sends only the attributes needed or a restricted verification result. The operational layer checks the reservation and any open requirements. The lock system receives the unit, the period for which access is valid, and the authorization status. It has no need for the guest's document number, nationality, or portrait.

A secure process also needs a fallback. Phones lose power or network access, electronic evidence can be revoked, and some guests will not use a wallet. Each of those ordinary situations needs a workable route to review and entry.

Keep the underlying data apart

Electronic proof is not inherently more private than a copy of a document. The privacy gain comes from asking for fewer details, restricting who may see them, and deleting raw material earlier. Swiss data protection law requires proportionality and purpose limitation, among other principles. Where the General Data Protection Regulation applies, its rules on data minimization and storage limitation are relevant too.

In practice, distinguish at least five categories:

• a document image or scan used for manual review
• biometric information or a selfie used for matching
• electronic attributes supplied by a wallet
• a restricted verification record showing the method, time, and result
• the statutory registration information and the technical record of access

Because these records serve different purposes, they need not be kept for the same period. A door code expires with the stay. The document image may no longer be necessary once the review is finished. A cantonal rule may prescribe how long the registration form is retained. For an unresolved incident, a restricted record of the result may still be needed.

An inquiry concerning Airbnb by the Irish Data Protection Commission provides a useful example. The Commission objected to identity documents remaining in storage after verification had ended, while allowing that a limited record of the verification could remain. Its decision does not create a general retention rule for Switzerland. It illustrates, however, why an image of the document and a record of the result should be managed separately.

An audit trail need not retain every item collected during a check. It should show which kind of evidence was examined, which role approved an exception, and when an authorization changed or was withdrawn. The article on audit trails for operational evidence addresses that balance in greater depth.

Set the rules before connecting another system

Begin with a profile for each location and operating model, not with the API. Write down the four decisions, the least information needed for each, and the manual alternative. Assign the roles, set out the status changes, and decide when each category of data is deleted. Only then is there a clear purpose for integrating a wallet.

Within the scope that has been published, made available, and agreed, Oprivia can bring stays, tasks, roles, deadlines, evidence, and decisions into one operational process. It does not issue a government e-ID, act in place of a cantonal registration authority, or determine whether particular evidence has legal recognition. No connection to a wallet, public portal, or access system should be assumed. Any interface must be technically available, examined for the intended operational use, and expressly agreed.

A sensible pilot is deliberately small: one location, a limited number of evidence types, and a clearly staffed route for manual review. Completion time matters, but it is not the only measure. Also record mismatches, cases in which guests do not finish the process, data collected without a clear need, and access by people who should not have been able to see it.

Common questions about digital guest identity

Does the Swiss e-ID replace a passport or other travel document?

No. The federal government expressly describes the e-ID as something other than a travel document. Whether a process accepts electronic evidence depends on its legal basis and technical implementation.

Will the e-ID replace the cantonal guest-registration form?

No, not as a general rule. It may supply identity data, while the filing, deadline, required fields, and means of transmission continue to follow federal law and cantonal or municipal practice.

Must every vacation rental accept an EU Wallet?

No. The European framework places no general acceptance duty on every private host. Any duty depends on the service, the role of the provider, and the relevant legal basis. Even a voluntary wallet option needs an equivalent alternative.

Does a verified platform account satisfy guest-registration duties?

No. A platform performs verification for its own purpose, and the result may be incomplete for local registration. The host remains responsible for the procedure required where the property is located.

May a positive identity result trigger a door code?

Only where a complete set of rules also checks the reservation, unit, permitted time, and unresolved exceptions. The process must provide for revocation, manual review, and another route when the digital path fails.

Digital identity can make check-in easier, but it does not replace registration, approval, or access control. Operators should collect only the data needed for each step and record who made each decision.