Updated July 2026.
A scheduled smart-lock code depends on more than a start and end time. The lock, app, hub, phone, cloud account, property, and event log may use different time zones, UTC offsets, clocks, or daylight-saving rules. A skipped hour can prevent access; a repeated hour can extend it; an offline lock can keep an old schedule; and a timestamp mismatch can confuse an incident review. This checklist turns time-based access into a record that can be tested before a cleaner, carer, contractor, guest, dog walker, or short-term renter depends on it.
Build a time and access record before creating the schedule
| Field | Record | Why it matters |
|---|---|---|
| Person and purpose | Name or supported identity, organization, approved task, host, and verification method | Prevents anonymous codes and makes the access decision reviewable |
| Door and area | Exact exterior or interior door, permitted rooms, alarm mode, camera boundary, key or elevator limits, and egress route | A front-door code should not silently grant garage, side-gate, alarm, camera, or building-wide access |
| Time | Named time zone where shown, UTC offset, device and app displays, start, end, recurrence, daylight-saving rule, early-arrival rule, overrun owner, and review date | A skipped, repeated, stale, or misread local time can deny or extend access |
| Credential | Code or account owner, creation time, creator, delivery method, wrong-code behavior, history, and deletion route | Shared text messages, reused codes, and unknown creators weaken control |
| Fallback and response | Host contact, approved physical fallback, outage route, lockout process, property contact, and emergency boundary | Prevents unsafe improvisation when the phone, account, hub, internet, battery, or door fails |
Use the minimum access the visit requires
Give each supported person a separate credential. Limit it to the approved door, time, alarm authority, camera access, and automation scope. Do not share the owner account, household master code, recovery email, installer code, Wi-Fi administrator, or one permanent code among unrelated workers.
Record who may unlock, see history, create other codes, change schedules, invite users, disarm an alarm, view cameras, trigger voice control, edit automations, reset the lock, or recover the account. If the platform cannot separate those roles, write the limitation and decide whether the visit needs a different control method.
Choose time-window rules for each visitor type
| Visitor | Suggested control pattern | Closure evidence |
|---|---|---|
| One-time guest or delivery helper | Single visit window with a short buffer and host confirmation | Expired code fails; no app, camera, alarm, voice, or recovery access remains |
| Cleaner, dog walker, or carer | Named recurring schedule limited to expected days and hours, with quarterly review | Missed, changed, and ended service dates are reflected; old access fails |
| Contractor or installer | Project window, approved door and work area, host or manager owner, and same-day closeout | Code, app, installer session, automation, alarm authority, and copied physical key are reconciled |
| Short-term renter | Stay window in the property’s time zone, unique credential, checkout deadline, and cleaning transition | Prior guest fails before the next guest begins; owner and recovery controls remain with the property |
| Family or regular guest | Separate identity with a stated ongoing need and scheduled review rather than a shared master code | Access is removed promptly when the need changes; history remains attributable |
The smart-lock access-code audit provides a broader recurring review of residents, workers, guests, codes, sessions, and recovery.
Deliver credentials without creating a second leak
- Verify the recipient through an approved contact route before sending a code or invitation.
- Do not place the address, alarm instructions, recovery details, and long-lived code in one unprotected message.
- Tell the guest which door, time zone, start, end, normal entry step, lock confirmation, host contact, and emergency boundary apply.
- Require the recipient not to forward, reuse, photograph publicly, or store the credential beyond the approved need.
- Record delivery and acceptance without retaining sensitive access data longer than the property requires.
Separate lock access from alarm, camera, and automation authority
An unlock should not automatically prove identity, disarm the alarm, suppress a warning, open a garage, reveal cameras, or disable a privacy mode. Draw every rule linking the credential to arming, disarming, entry delay, lights, cameras, thermostats, voice assistants, presence, gates, garages, or monitoring. Give each rule a named owner, manual override, rollback, and test.
For a sensor-led alarm, name the entry zone and delay separately from the lock code. A digital unlock event does not prove the door opened, closed, latched, or was used by the intended person.
Test schedule start, schedule end, deletion, and every copied route
- Create a temporary test user using the same role and schedule pattern planned for the real visitor.
- Before the window, prove the code and app role fail. At the start, prove they work only on the approved door and do not expose extra history, users, cameras, alarm controls, or settings.
- During the window, test entry, lock confirmation, named history, notification, door-state sensor, entry delay, and host response without creating an emergency dispatch.
- After the end time, prove the code, app session, invitation, shared link, voice route, automation, alarm authority, camera access, installer access, and recovery path fail.
- Check for a physical key, copied code, offline credential, cached app session, secondary bridge, old phone, watch, keypad, or property-management integration that may remain.
Prove clock, daylight-saving, restart, and outage behavior
| Condition | Test | Pass condition |
|---|---|---|
| Internet unavailable | Disconnect internet without resetting the lock or router | Approved local behavior is known; remote creation, revocation, alerts, history, and reconnect are documented |
| Hub or bridge unavailable | Power down the integration layer separately | Keypad, physical fallback, direct door state, alarm delay, schedule, and restoration remain predictable |
| Battery low or dead | Follow the exact maker’s warning and emergency-power instructions | Warnings arrive early, fallback works, stored schedules survive, and time remains accurate |
| Clock or time zone changes | Test the property’s zone, UTC offset, spring-forward gap, fall-back repeated hour, manual phone-zone change, device restart, hub restart, and app display | Start and end occur at the intended property time; repeated or missing times fail as documented; history uses an understood timestamp |
| Owner unavailable | Use the documented second administrator and recovery route | Access can be revoked and the property can recover without exposing the owner credential |
Use the smart-lock lockout recovery checklist for safe keys, batteries, accounts, property contacts, and locksmith routes. The renter no-subscription lock guide adds landlord permission, move-out, and permanent unpaid-state checks.
Close access when a visit, job, stay, or relationship ends
- Confirm the approved work or stay ended and identify unresolved return visits, keys, equipment, packages, or incidents.
- Expire or delete the credential, remove the user, revoke sessions and invitations, and disable linked voice, automation, alarm, camera, installer, and recovery access.
- Collect or rekey physical keys where required, inspect the door and lock, and preserve relevant lawful access or camera records before deletion.
- Run the failed-access test from outside without creating a real lockout. Confirm the old route fails and the owner and second administrator retain approved control.
- Update the access register, incident record, billing or service end, return-period or warranty notes, and next review date.
For a move, sale, manager change, or staff transition, use the smart-home security handover checklist.
30-minute time-zone and daylight-saving acceptance test
- Reconcile the door, lock, direct door-state sensor, physical fallback, app, owner, second administrator, guest role, alarm, camera, automations, network, power, time zone, support, and recovery.
- Create a test guest. Prove pre-start denial, valid-window entry 10 times, correct user history, door-state evidence, entry delay, notification, and lock confirmation.
- Disconnect internet and the hub or bridge separately. Record local entry, schedule, revocation limits, alerts, history, reconnect, and restoration.
- Expire and remove the test guest. Prove code, app, invitation, session, voice, automation, alarm, camera, installer, and recovery routes fail.
- Complete a tabletop cleaner, carer, contractor, and short-term-rental change. Confirm who creates, extends, revokes, investigates, recovers, and accepts each access period.
The installation acceptance test covers fit, state, codes, outages, and handover before the return period ends. Compare the current Abode Lock, Smart Security Kit, and plans against the same access, alarm, offline, user, ownership, and recovery tests.
Smart-lock time zone and daylight-saving FAQ
Which time zone does a smart lock schedule use?
The answer depends on the exact lock, app, hub, cloud account, phone, and property settings. Record the displayed zone and UTC offset, then test start, end, history, and notifications at the property before relying on a schedule.
Will a smart lock adjust guest schedules for daylight saving time?
Do not assume it will. Test the exact lock across the relevant clock change, including skipped or repeated local times, offline behavior, event history, notifications, and restoration.
Can a smart-lock event log use a different time from the code schedule?
Yes. The lock, app, hub, cloud service, camera, alarm, router, and phone can display different zones, offsets, or delayed events. Preserve the original display and record the observed difference instead of silently changing evidence.
What happens to a scheduled code during an internet outage?
Test the exact lock before relying on it. Local keypad, Bluetooth, physical key, hub, remote app, notification, history, and schedule behavior can fail differently. Keep an approved fallback that does not depend on the same phone, account, bridge, and broadband connection.
