A rental smart lock is not ready for the next resident when one keypad code has merely been changed. Turnover must remove old accounts, phones, codes, keys, automations, camera access, alarm permissions, and recovery paths; verify door fit and batteries; test failures; and hand control to the correct owner and resident.
Smart-lock turnover at a glance
| Area | Pass condition | Common failure |
|---|---|---|
| Ownership | The lawful owner or manager controls the lock and recovery | A former resident or installer remains primary owner |
| Credentials | Old codes, phone keys, cards, fingerprints, and shares all fail | Only the visible keypad code was changed |
| Mechanical access | Keys are accounted for and rekeying follows the property plan | An unknown physical key still works |
| Door fit | The bolt moves freely with the door open and closed | The motor strains against a misaligned strike |
| Integrations | Alarm, camera, voice, and automation access match the new tenancy | A departing resident keeps indirect access through another app |
| Handover | The new resident receives named access, privacy terms, support, and tests | Everyone shares an undocumented master code |
1. Confirm authority and the turnover boundary
Identify the property owner, manager, outgoing resident, incoming resident, installer, cleaner, contractor, and any short-term guest roles. Follow the lease, local access and rekeying rules, fire and egress requirements, privacy law, and building policy. Do not delete evidence, lock out a lawful occupant, or change access before the authorized turnover time.
2. Freeze changes and export the record
Before removing access, record the lock brand, model, firmware, serial, account owner, administrators, users, codes, keys, credentials, hub or bridge, battery type, integrations, automations, warranty, and support case. Export access history only when lawful and necessary. Keep sensitive codes and movement records out of shared maintenance notes.
3. Audit every form of access
| Credential | Turnover action | Acceptance test |
|---|---|---|
| Owner/admin account | Transfer or confirm lawful ownership and recovery | Old owner cannot administer after handover |
| Phone key / app share | Remove user, device, home membership, and trusted session | Old phone cannot unlock locally or remotely |
| Keypad code | Delete named resident, guest, cleaner, and contractor codes | Each removed code fails; new named code works |
| Fingerprint / card / watch / wallet key | Remove from lock and linked platform | Removed credential fails at the door |
| Mechanical key | Count, recover, rekey, or replace under the property plan | Only authorized keys work |
| Voice / automation | Remove linked accounts, routines, and broad household roles | Former users cannot unlock or disarm indirectly |
4. Remove access from every connected platform
Check the lock app, Apple Home, Google Home, Alexa, alarm app, property-management platform, camera app, hub or bridge, router, password manager, mobile wallet, installer portal, and any short-term rental service. Removing a keypad code does not remove an Apple, Google, Amazon, manufacturer, or alarm-system role.
5. Rekey or account for the mechanical path
A retrofit smart lock may leave the existing cylinder and keys unchanged. Decide whether the cylinder must be rekeyed, replaced, or documented. Count owner, resident, cleaner, contractor, mailbox, garage, gate, common-entry, and emergency keys. Never disable required emergency egress or building access.
6. Inspect the door before testing electronics
Check slab, frame, hinges, strike, deadbolt, latch, weather stripping, handle, glazing, inside release, and fire-door requirements. Extend and retract the bolt by hand with the door open, then closed without pushing, pulling, lifting, or slamming. Correct alignment before recalibrating the motor.
7. Replace or verify batteries
Use the maker-approved battery type and replacement process. Record installation date and expected review date. Test low-battery warnings, emergency power, mechanical entry, and battery removal behavior without creating a lockout. Do not mix old and new cells unless the manufacturer explicitly allows it.
8. Reset only when the ownership plan requires it
A factory reset can remove users, history, calibration, integrations, and recovery, but it can also create downtime or erase evidence. Confirm authorization, export needed records, keep a mechanical key on the secure side, and document the exact reset and recommissioning steps. A reset is not a substitute for verifying every linked account.
9. Create named access for the new resident
Give each resident a named account or code with minimum permissions. Avoid one shared master code. Set guest, cleaner, contractor, and maintenance access with clear schedules and expiry. Explain who can view access history, manage users, unlock remotely, connect voice assistants, or link the lock to an alarm.
10. Test door state, auto-lock, and history
Verify locked, unlocked, open, closed, ajar, jammed, low-battery, invalid-code, and offline states where supported. Test auto-lock with the door closed and deliberately ajar. Confirm the app cannot report a secure doorway merely because the bolt extended into empty space. Check named-user and timestamp accuracy.
11. Audit alarm, camera, and automation behavior
Test whether unlocking disarms an alarm, starts a camera routine, turns on lights, changes a thermostat, or sends a notification. Define which credentials may trigger each action. Remove old residents from alarm and camera roles. Treat unlock-to-disarm as high risk and verify forced entry remains visible.
12. Run one-failure-at-a-time tests
| Failure | Safe test | Record |
|---|---|---|
| Internet down | Disconnect WAN while keeping local power | Local access, remote control, alerts, history, recovery |
| Hub or bridge down | Power off the named dependency | Direct access, integrations, fault timing, restoration |
| Phone unavailable | Lock away the owner phone | Key, keypad, resident access, support path |
| Battery unavailable | Use the maker-approved test | Warning, emergency power, key path, replacement |
| Account recovery | Verify without changing ownership | Email, MFA, trusted device, support identity checks |
Use the smart-lock acceptance test and battery/outage checklist for commissioning details.
13. Complete the handover
Give the new resident the physical keys, named credentials, owner or resident role, privacy explanation, emergency entry method, battery type, support details, fault procedure, test results, and next review date. Remove installer and temporary turnover access while all parties can verify the result. Store the record with the security-system documentation checklist.
14. Schedule post-move checks
Repeat door fit, access, battery, and history tests after 24 hours, after one week, after weather changes, and after any firmware, router, hub, account, resident, cleaner, or contractor change. Review codes and members at least quarterly and at every turnover.
Where Abode fits
For an Abode property, verify the exact lock integration, Abode app users, alarm permissions, CUE automations, camera access, event history, monitoring contacts, and outage behavior. Compare the Abode Lock, Smart Security Kit, and current Abode plans.
FAQ
Is changing the keypad code enough between tenants?
No. Audit owner and member accounts, phone keys, fingerprints, cards, wallet keys, mechanical keys, alarm roles, cameras, voice assistants, and automations.
Should a smart lock be factory-reset at every turnover?
Only when authorized and appropriate for the ownership plan. Export needed records, preserve emergency access, and verify every linked account either way.
Who should own the smart-lock account?
The lawful property arrangement should define ownership. Residents should receive named minimum access and clear privacy and recovery terms.
How do I prove an old resident no longer has access?
Test every removed code, phone, card, biometric, key, platform role, and indirect automation after revocation.
Build a credential-revocation pack before the keys change hands
A turnover record should prove more than “the code was changed.” Build one row for every path that can unlock, administer, recover, or indirectly control the door. Name the owner, current user, expiry time, removal action, test device, result, and person who approved the handover. Keep secret values out of the shared copy; record the credential label and result instead.
| Access path | Evidence to keep | Pass condition |
|---|---|---|
| Lock owner and administrators | Named role list, recovery owner, removal time | Only the approved owner and current administrators remain |
| Keypad codes and biometrics | Credential label, schedule, deletion result | Every departing credential fails and each new named credential works |
| Phone keys and app sessions | Member list, trusted devices, session revocation result | A departing phone cannot unlock locally or remotely |
| Mechanical keys | Count, key numbers where lawful, rekey record | Only accounted-for keys operate the cylinder |
| Home and alarm platforms | Household roles, alarm permissions, routines | No former user can unlock, disarm, view, or invite indirectly |
| Recovery and support | Recovery email, phone, MFA, support identity | Recovery belongs to the approved owner and works without a former resident |
Separate lock removal from account and session removal
Deleting a code at the lock does not close a trusted phone, browser session, Apple Home membership, voice-assistant household, alarm role, camera share, or password-manager item. Use the trusted-device and session audit to list every signed-in device and revoke it from the server side. Then test the old phone on Wi-Fi, cellular data, and Bluetooth if the lock supports more than one path.
Record the exact test state. “User removed” is an administrative observation. “Old phone failed locally and remotely after refresh and re-login” is an acceptance result. If a platform caches access while offline, follow its documented expiry behavior and retest after the stated window.
Move residents out of the connected home, not only the lock app
A resident may have been invited through Apple Home, Google Home, Alexa, an alarm platform, a property-management service, or a lock maker’s app. Work through the HomeKit renter move-out checklist when Apple Home is present. Remove the person, their owned bridges where appropriate, personal automations, shared cameras, and any remote-access path that depended on their hub.
Do not delete a resident-owned device or account without authority. First decide which devices stay with the property, which leave with the resident, and which platform will own the home after turnover. A factory reset performed before that decision can strand accessories or erase evidence without removing a server-side household role.
Rekey the physical path as its own work item
Phone and keypad cleanup does not account for copied metal keys. Use the smart-lock rekeying checklist to confirm cylinder type, authorized keys, building master-key rules, emergency access, locksmith work, and the post-rekey test. Keep the door open during the first mechanical and electronic tests so a bad cylinder, calibration error, or low battery does not create a lockout.
For common entrances, gates, mailrooms, garages, and fire doors, coordinate with the building or strata plan. A unit-door turnover must not accidentally break a lawful shared-entry or emergency-egress path.
Remove camera viewers and exports
A lock handover can leave a more serious privacy gap if a former resident still sees the entry camera. Run the security-camera shared-user access audit for each doorbell, indoor camera, recorder, cloud account, export folder, and notification group. Check whether the removed person can view live video, receive clips, download evidence, speak through the camera, change privacy zones, or invite another viewer.
Retest from a non-owner account. The owner’s successful view proves that the service works; it does not prove that the former viewer has been removed. Document consent and retention rules for any entry camera that remains active between tenancies.
Change recovery material without creating a single point of failure
Move recovery codes, owner credentials, support records, and shared secrets into the approved property record. The password-manager and recovery-code audit helps separate owner recovery from resident day-to-day access. Rotate any shared password or code that a departing person knew, even when their named account has been removed.
Keep two authorized recovery paths that do not depend on the same phone, email account, or resident. Test recovery far enough to confirm the destination and identity checks, but stop before taking ownership away from the active administrator unless a transfer is scheduled and approved.
Retest auto-lock and indirect alarm actions
Turnover often changes schedules, time zones, household presence, and the people allowed to disarm. Use the smart-lock auto-lock checklist to test door-open state, delay, guest access, egress, jam behavior, and recovery. A bolt extending on an open door is not the same as a secured doorway.
List every automation that reacts to an unlock, lock, arrival, departure, alarm mode, or camera event. Confirm whether a new-resident code should disarm the alarm, whether a cleaner code should work only on a schedule, and whether a maintenance code can ever trigger an away-to-home routine. Disable any rule with no named owner or unclear response.
Run a 45-minute turnover revocation and handover test
- Freeze changes and list the lock, cylinder, bridge, hub, router, alarm, cameras, home platforms, administrators, residents, guests, cleaners, contractors, and recovery owners.
- Remove one departing credential at a time. Test its keypad, phone, biometric, card, wallet, voice, and mechanical paths before moving to the next row.
- Refresh and sign out the old phone, then test local Bluetooth, property Wi-Fi, cellular remote access, and any home-platform control.
- Remove the person from connected-home, alarm, camera, and property-management roles. Confirm they cannot invite another user or change an automation.
- Count and test mechanical keys under the approved rekey plan. Keep one authorized emergency key outside the test path.
- Create named incoming-resident access with the minimum role, a clear schedule, and no shared master credential.
- Test lock, unlock, ajar, jam, invalid code, auto-lock, low battery, internet loss, bridge loss, app loss, and recovery.
- Trigger each approved unlock-to-alarm or camera automation with the correct credential, then with a credential that should not trigger it.
- Check timestamps, named-user history, notifications, camera access, and the owner’s ability to remove the new test user.
- Give the resident the approved keys, access method, privacy notice, battery and outage instructions, support route, and next review date.
Pass: all departing access paths fail, all approved incoming paths work, physical keys are accounted for, indirect platforms match the tenancy, recovery belongs to the approved owner, and the household can repeat the outage and lockout steps. Fail: any old credential still works, a former resident retains video or alarm access, ownership is unclear, a shared master credential remains, the bolt binds, or recovery depends on the departing person.
Turnover launch blockers
- A former owner, administrator, home member, camera viewer, alarm user, or trusted session remains active.
- An unaccounted mechanical key or building credential still works.
- The door needs force to latch or the motor reports locked while the doorway is not secure.
- The incoming resident must use a shared owner password, master code, or undocumented phone.
- Unlocking can disarm the alarm through an unnamed or untested automation.
- Recovery email, phone, MFA, or support identity belongs to a former resident or contractor.
- The entry camera remains visible to an unapproved viewer.
- There is no tested key, emergency-power, lockout, or support path.