Plan mobile access when an employee changes phones

Quick answer: Treat a phone replacement as a controlled access transition, not just an app download. Verify the person's account, the supported unlock method on the new device, and the status of credentials or sessions on the old one. Test the normal entry route before relying on the replacement, and provide an approved fallback if the old phone is lost or unavailable.

A restored phone backup can make the new device look familiar while leaving door access unfinished. The application may be present but signed into the wrong organization, missing a required permission, or waiting for a credential step that was not transferred with ordinary phone data.

The business also needs to consider the device being replaced. An old phone in a desk drawer and a lost phone present different circumstances, but both require a deliberate review of access. A successful unlock on the new device does not prove that the old one can no longer be used.

Separate a planned replacement from a missing device

For a planned upgrade, schedule the transition while the person still has access to the old device and the appropriate support contact. That provides an opportunity to complete supported removal, enrollment, and testing before the next early-morning arrival.

If the old phone is lost, use the organization's incident and credential process first. The responsible administrators should determine the necessary account, session, or credential actions for the platform. Do not postpone that review merely because a new phone has already been ordered.

Identify whether the device belongs to the business or the employee and which teams manage it. A corporate mobile-device process may need to coordinate with the physical-access administrator. Those responsibilities should be clear without requiring staff to share personal passwords or surrender unrelated private information.

For a hypothetical employee changing phones before travel, the useful test may include access at more than one office. Completing enrollment at headquarters is not enough if the next required entrance uses a different approved method or local configuration.

Identify the credential and unlock method in use

Ask which method the person actually uses at the door. Reader-based tapping, an in-app unlock request, and a wallet credential can have different enrollment and device requirements. A general statement that mobile access is supported does not explain how the new phone should be prepared.

Kisi's mobile credential documentation distinguishes reader-based Tap to Unlock, in-app cloud requests, and MotionSense. These methods illustrate why the test must match the configured workflow. Success with one method should not be presented as proof that every other method works on the same phone.

Confirm the exact reader and platform configuration at the relevant sites. If the person is moving between phone operating systems or device types, have the administrator verify support for the intended method. Avoid assuming that a familiar gesture has identical behavior across every device and reader.

The mobile credentials and key cards guide helps organize that comparison. The goal is an approved, usable way for the person to enter, including any practical constraints that should be understood before the older credential is retired.

Recover the correct account through approved channels

Confirm the organization's account or domain and the person's approved identity. A phone may contain several work-related applications or memberships, and reinstalling the access app does not necessarily select the correct one. Use the platform's supported sign-in or invitation process.

Kisi's onboarding guidance specifically describes organization sign-in and permissions needed for its mobile workflows. It also notes that managed-device profiles can affect access to NFC and Bluetooth. Those are practical setup dependencies, not reasons to bypass the organization's device controls.

Have the appropriate identity administrator help if the person cannot complete sign-in or required authentication. The door-access team should not solve the issue by sharing another user's account. Keep identity recovery and door-permission approval connected while preserving their separate responsibilities.

For a hypothetical managed phone, a work-profile restriction may prevent the intended reader interaction even after the user signs in successfully. The right next step is a supported review with the device-management team, not instructing the employee to remove management controls simply to make the entrance test pass.

Review the old phone's remaining authority

Ask the platform administrator what the replacement process changes on the old device. Depending on the system, relevant objects may include app sessions, device registrations, mobile credentials, or wallet passes. Determine which must be revoked or removed and what evidence confirms that result.

Kisi documents management of obsolete logins, including administrator removal when a user cannot reach an old login. That is a specific supported capability. It should not be generalized into a claim that uninstalling any access app or signing into a replacement automatically revokes every previous credential.

Consider associated devices where applicable to the organization's chosen method. An employee may also use another enrolled device or a separate credential that is not part of the phone replacement. Review those deliberately instead of either ignoring them or deleting all access indiscriminately.

Preserve the person's legitimate door permissions unless the approved change requires otherwise. Replacing a phone normally changes the means of access, not the business reason for entering. Avoid creating a second user identity merely because the new device needs enrollment unless the platform's supported process specifically requires that arrangement.

Test the ordinary entrance experience

Use the employee's normal route, account, and supported unlock gesture. Confirm the required doors work during the approved schedule, and inspect the relevant event information with the administrator if the result is unclear. An app displaying a door name does not by itself prove that the phone can complete the intended entry.

Test the conditions that matter to ordinary use without inventing a universal offline promise. The relevant network, device, reader, and controller requirements depend on the selected method. If outage operation is important, have the technical team define and conduct an appropriate controlled test separately.

A practical replacement check includes:

• Correct organization identity and current door assignments.
• Supported phone, application, and intended unlock method.
• Required permissions under the organization's device policy.
• Successful entry through representative approved openings.
• Confirmed disposition of obsolete device sessions or credentials.
• A clear temporary-access route if an unresolved issue remains.

Do not broaden the user's door permissions to troubleshoot a device problem without understanding the cause. A failure can arise from enrollment, method support, phone permissions, schedule, or the physical opening. Preserve that distinction so the fix addresses the real dependency.

Provide a fallback that does not become permanent clutter

If the new phone is not ready, use the organization's approved alternative for verified users. That may involve a properly assigned temporary credential or an attended entry process. The choice should match the site, operating hours, and the person's actual authorization.

Give temporary access a clear end and disposition. Otherwise a routine phone change can leave an extra active card or exception attached to the person long after the problem is solved. Make the closure step part of the same support request that issued the fallback.

For a hypothetical employee starting before reception opens, an attended daytime workaround may not be sufficient. Plan for the actual arrival time and ensure the authorized support route is reachable. Operational fit matters as much as whether a temporary credential can be created technically.

Keep staff instructions short and concrete. They should know which entrance to use, which credential is currently valid, and whom to contact if it fails. Do not leave the employee to guess between several partially configured access methods during a busy shift change.

Finish with a clean identity record

After testing, confirm the new device is associated with the intended identity and that obsolete records have the appropriate status. Retain a concise support history under the organization's process. Avoid storing unnecessary device screenshots, personal information, or authentication details in a broadly shared ticket.

Check whether any replacement license, credential allocation, or temporary issue needs administrative reconciliation. Commercial and inventory behavior varies by platform, so confirm it through the applicable account process rather than assuming every device transfer is free or consumes the same entitlement.

Use recurring support problems to improve onboarding instructions. If users repeatedly sign into the wrong organization or miss a required managed-device permission, add that specific check. A short verified guide is more helpful than a long list of troubleshooting steps copied from unrelated phone models.

Include phone replacement in future system demonstrations. Ask vendors to show a planned change, a lost-device case, and a user who needs access at two sites. That exercise reveals whether the administration and fallback process fits the business before mobile credentials become its primary entry method.

The takeaway

A new phone should become a verified replacement for the approved access method, with the old device's authority handled explicitly. App presence, successful sign-in, and a working door unlock are separate milestones.

Coordinate identity, device management, and physical access, then test the real entrance experience. Close temporary permissions and obsolete registrations so a routine hardware upgrade leaves a clear, supportable credential record.

Plan mobile access beyond initial enrollment

BlueHouse Telecom helps businesses scope electronic access control nationwide, including mobile credential workflows, reader compatibility, and practical support scenarios.

FAQ

Will restoring a phone backup automatically restore door access? Do not assume it will. The app, account, credential, and permissions may require separate supported steps. Verify the actual unlock method at the required doors before relying on the new device.

Does signing in on the new phone disable the old phone? Behavior varies by platform and credential type. Have the administrator confirm which old sessions or credentials remain and use the supported removal or revocation process where required.

Should a phone replacement create a new employee identity? Usually the goal is to preserve the approved identity and permissions while changing the access device. Follow the selected platform's supported workflow and avoid unnecessary duplicate user records.

What if the employee needs entry before setup is finished? Use an approved, verified fallback with a defined scope and end. Confirm it works for the person's actual arrival hours, then retire it when the mobile replacement has passed testing.