How to hand over digital access, admin rights and 2FA in a succession

A succession often turns on digital access. The successor needs access to business email, accounting, cloud storage, payment approvals or administration portals. A sheet of passwords does not complete that transfer. The legal allocation, the correct role, new two-factor authentication and a documented final check all matter.

This article covers contractually or organisationally transferable administration and usage rights. Personal accounts do not automatically pass to another person. The provider, account ownership and specific function must be checked in each case. The succession planning section provides the wider legal framework.

Which digital rights belong in the handover file

Start with a complete system list. Include business email and calendar administration, accounting, payroll, cloud storage, payment and banking portals, inventory systems, CRM, hosting and internal administration. The business function matters. The successor must see which system supports which task.

Section 914 of the Austrian General Civil Code requires agreements to be interpreted by considering the parties' intention and fair commercial practice. For digital rights, a general reference to all passwords does not identify the account, role or scope. The handover agreement should allocate systems, responsibilities and the changeover time expressly.

Record dependencies as well. A payment portal may depend on a business email, mobile phone or second approver. A backup may depend on a cloud administrator. These connections should be visible before old access is closed.

Separate admin rights from personal accounts

A business account with several roles is different from a personal profile of a natural person. An organisation may provide for a transfer or a new administrator appointment for a business administration account. Provider terms, identity checks and the account's purpose also matter for a personal profile.

The successor therefore does not receive a blanket right to all accounts used by the transferor. First establish whether an account belongs to the business, a company, a service provider or an individual. Then agree the permitted change with the provider. Section 914 of the Austrian General Civil Code supports an interpretation by economic purpose, but it does not replace mandatory provider terms or create transferability where none exists.

The article on company register entries and powers of attorney complements this digital level. It explains why internal rights, corporate representation and technical access must be considered together.

Change 2FA when responsibility changes

Two-factor authentication, or 2FA, requires a second proof in addition to a password. It may be an authenticator app, SMS, security key or confirmation on a registered device. In a succession, that second factor must be assigned to the new responsible person or to a defined business role.

The order matters. Register new devices or keys, perform a sign-in and test recovery first. Only then remove or replace old sessions, devices, phone numbers, app keys and recovery codes. A second authorised person should confirm the test for critical systems.

Passwords and recovery codes do not belong in unprotected email or in the same file as the rights matrix. A secure password manager, a provider-supported role change or another controlled method may be suitable. The method depends on the system, the risk and the agreement.

A handover protocol proves the digital completion

A useful handover protocol describes the state before and after the change. For each system record its name, URL or technical identifier, business purpose, former and new role, changeover time, handover method and test status. Do not place passwords in the protocol.

The record should also show which old rights were closed. This can include active sessions, former administrators, recovery addresses, API keys, app passwords and approval devices, where the system offers those functions. If closure is not yet possible, record the reason, responsible person and follow-up date.

The protocol is a completion list and does not replace the handover agreement. It shows how the agreed change was implemented. If questions arise later, it distinguishes a role that was never transferred from one that was prepared, tested and completed.

Consider data protection when granting admin rights

Admin rights often open access to personal data. Examples include customer data in a CRM, employee information in payroll, email or support cases. Article 5 GDPR covers purpose limitation, data minimisation, integrity and confidentiality. Article 24 assigns responsibility for suitable organisation to the controller. Article 32 requires appropriate technical and organisational measures.

For a succession, this calls for a rights matrix based on tasks. The successor needs the rights required for the role. The transferor keeps access only where there is a specific business reason. The change is coordinated with the role description, the protocol and the organisation's responsibilities.

The article on customer data, newsletters and GDPR addresses the data-stock perspective. This article focuses on access control. The questions can meet, but their checks remain distinct.

Organise the digital handover in phases

Signing, completion and the actual management takeover do not always occur on the same day. The handover file should therefore distinguish three states: prepared, technically tested and finally changed. For the interim period, define the purpose, scope and duration of every remaining old access.

A practical sequence starts with an inventory and an ownership check. Then create new roles, test 2FA and recovery, and review the key systems together. Close old rights only once the successor can operate the systems. Banking and payment approval also need a coordinated approval chain.

The documents for the first succession consultation help organise the agreement, powers and people involved. Add system owners, providers and technical open points for the digital handover.

Common mistakes with admin rights and 2FA

A frequent mistake is transferring one master password without checking roles. That leaves account ownership and provider permission unclear. Another is closing the old factor before testing the new access. That can interrupt operations.

A signed handover protocol alone also does not prove working access. The sign-in, test approval and final role check should be recorded. A successful login is likewise insufficient if former administrators and recovery routes remain active.

The articles of association in succession section can matter for responsibilities and approval requirements. Technical administration does not replace required resolutions or representation rules.

What should be complete on the handover date

The closing file should contain a system and account list, rights matrix, responsibility agreement, secure handover method and test record. Also record which old devices, sessions, recovery addresses and tokens were closed or replaced.

Give every open point a responsible person and a date. This includes provider confirmations, pending role changes and systems requiring manual review. The file should allow the new management to understand the position without exposing passwords in plain text.

This final check clarifies the actual completion. It also helps when the succession takes place in several steps and some systems can only be changed after the handover date.

Questions about digital access in a succession