A smart-lock access log can answer which credential unlocked a door and when the event occurred. It can also create false confidence. Shared PINs, wrong time zones, offline locks, deleted users, copied keys, delayed cloud sync, and missing events can make a clean-looking timeline incomplete.
This 2026 smart-lock access-log audit shows homeowners, landlords, small businesses, and property managers how to test identity, timestamps, event coverage, retention, privacy, export, and outage behavior. The goal is not constant surveillance. It is a record whose limits are understood before an incident.
The short answer
Give every regular user a named credential, separate people from devices and automation events, correct the lock and account time zone, create a controlled event set, compare local and cloud timelines, test the lock offline, document retention and deletion, restrict log viewers, and export one incident packet without changing the original record. Do not pass the audit until manual keys, inside thumb turns, failed PINs, app actions, keypad actions, and outage events are either recorded correctly or listed as blind spots.
Start with the access question
Do not collect logs without a defined use. Choose the questions the record must answer:
- Did an approved credential unlock the door during an allowed window?
- Was the event created by keypad, phone, automation, voice assistant, remote administrator, or physical action?
- Did the door merely unlock, or did a separate sensor show it opened?
- Was the lock online when the event occurred?
- Can an administrator distinguish a failed credential from a successful entry?
- Can a former user be removed without erasing the meaning of past events?
- Can an incident timeline be exported without exposing unrelated household activity?
These questions determine which users, tests, fields, and retention controls matter. A family home may need simple accountability and lockout troubleshooting. A rental or workplace may also need written authority, notice, and narrower access to records.
Map every system that can create or alter an event
| System | Possible event | Audit risk |
|---|---|---|
| Smart lock | Keypad, app, thumb turn, auto-lock, jam, low battery | Some local actions may be generic or absent |
| Vendor cloud | Remote action, user change, delayed sync | Internet loss can delay the visible timeline |
| Bridge or hub | Automation, remote command, connectivity change | The lock may not name the upstream rule or person |
| Apple Home, Alexa, or Google Home | App, scene, routine, voice, presence action | Labels can differ and may not identify the speaker |
| Alarm system | Unlock-to-disarm or arm-to-lock handoff | Alarm and lock clocks or names may not match |
| Door contact | Open, close, left open | Unlock does not prove the door opened |
| Camera or doorbell | Motion, person, recording | Video time, privacy, and retention differ |
| Property platform | Guest code creation, schedule, revocation | A dashboard change may not reach an offline lock |
Record the exact product, app, account owner, bridge, hub, integrations, and firmware. Do not assume the vendor app is the only source of truth.
Build a named credential register
An access log is only as useful as its user labels. Each person should have a separate credential where the product supports it. Record the person or role, credential type, issuer, allowed door, schedule, expiration, review date, revocation date, and whether the credential should create an identifiable event.
Do not record the PIN, password, setup code, or recovery code in the register. Use the smart-lock access-code audit to remove shared, unknown, duplicated, and stale entries before testing the log.
Separate identity from credential labels
| Observed label | Reasonable statement | Statement to avoid |
|---|---|---|
| Named keypad PIN | The PIN assigned to this user was accepted | This person definitely crossed the doorway |
| Named phone key | The lock accepted an action linked to this account or device | The account owner personally performed it |
| Remote administrator | An administrator account sent the command | The administrator was at the property |
| Automation or voice assistant | A linked service triggered the action | A specific resident caused it without upstream proof |
| Manual or thumb-turn event | The lock detected a mechanical action if supported | The log identifies the person |
| No event | No event appears in the checked source | No entry or action occurred |
Verify clock, time zone, and daylight-saving behavior
A timeline with the wrong clock can misorder a lock event, alarm signal, message, and camera clip. Check phone time, lock or hub time zone, vendor property location, alarm-panel time, camera time, property-platform time zone, and whether exports show local time, UTC, or an offset.
Create one event at a known minute and compare every system. Record the displayed time and difference. Repeat after a daylight-saving or property time-zone change. The time-zone and daylight-saving checklist provides a wider smart-home test.
Create a controlled event matrix
Run known actions with the door attended. Write the start time before each action and wait for the normal sync window before judging a failure.
| Test action | Expected record | Extra proof |
|---|---|---|
| Valid named keypad PIN | Successful unlock tied to the correct label | Door contact opens and closes |
| Invalid keypad PIN | Failed attempt or lockout where supported | Keypad response observed |
| Named phone key | Local or app unlock with device/user label | Phone and vendor-app activity |
| Remote administrator | Remote event distinguished from local action | Administrator account record |
| Inside thumb turn | Manual event where supported | Witness note and door contact |
| Physical key | Model-specific event or known gap | Witness note and door contact |
| Auto-lock | Automation event, not a named person | Rule and delay setting |
| Voice or smart-home routine | Integration or automation event | Upstream history where available |
| Blocked bolt or jam | Failure or incomplete-lock event where supported | Physical bolt inspection |
Do not create repeated failed-code attempts that could trigger a long lockout. Stop at the product’s documented test limit.
Pair unlock events with door state
An unlocked deadbolt does not prove a door opened. A locked deadbolt does not prove the door was fully closed. Compare the lock timeline with a named door contact:
- unlock the door;
- wait without opening it;
- open and close the door;
- lock with the door fully closed;
- repeat with the door slightly misaligned under safe supervision; and
- confirm the system distinguishes unlock, open, close, lock, and jam.
Use the security-zone naming guide so lock and contact events refer to the same door. If the bolt binds, fix it with the smart-lock alignment guide before trusting status history.
Test local and remote actions separately
A phone beside the lock may use Bluetooth while the same app away from home uses a bridge and cloud path. Run both tests: local phone action, remote phone action, keypad with the bridge online, keypad with the bridge offline, app after reconnection, and user revocation while the lock is offline followed by reconnection.
The last test matters for temporary credentials. A cloud dashboard may show a user as removed before an offline lock receives the change.
Run an outage and delayed-sync test
- Export or screenshot the current test timeline without exposing credentials.
- Disconnect only the bridge or internet path, keeping a working local entry fallback.
- Perform one keypad unlock, one manual lock, and one door open/close cycle.
- Note what remains visible locally and what disappears from the app.
- Restore connectivity and record how long each delayed event takes to appear.
- Check whether timestamps show event time or upload time.
- Confirm no events are duplicated, reordered, or assigned to the wrong user.
If the product offers no local history, record that limit. Do not describe a quiet cloud timeline as proof that nothing happened during an outage.
Audit administrators and log viewers
Access history can expose routines, absences, service visits, and occupancy. Review who can view, search, export, share, delete, rename users, add administrators, change retention, and transfer ownership.
Use individual administrator accounts and multi-factor authentication where offered. Remove former residents, employees, contractors, managers, and shared tablets. The security-account recovery-code audit helps check account ownership without placing secrets in the register.
Set a privacy and retention rule
Write the rule before an incident. Define the business reason, approved viewers, normal retention, incident hold, export approval, deletion method, and notice or consent required by lease, workplace policy, or local law.
Keep the shortest history that meets the approved need. Avoid copying a full household timeline when a narrow window answers the question. Technical access does not create authority to monitor a tenant, guest, worker, or family member.
Handle renamed and deleted users
Test what happens to old events when an administrator renames or deletes a user. A system may preserve the old label, apply the new label to history, replace it with a generic user, or remove the association.
- Create a temporary named test user.
- Generate one successful event.
- Rename the user and inspect the old event.
- Revoke or delete the user and inspect the event again.
- Export the timeline and compare labels.
Use a test credential that cannot access the property after the audit. Do not experiment on a resident’s active credential.
Build an incident export without changing the original
- Record the incident start and end time with time zone.
- Capture the original lock timeline and export format available.
- Record account, device, lock model, firmware, and app version.
- Export related door-contact, alarm, and camera events under the privacy rule.
- Save originals read-only where practical.
- Create a separate working timeline explaining clock differences and blind spots.
- Record who collected each item, when, and from which account.
- Do not rename users, reset the lock, or delete credentials until preservation is complete unless safety requires it.
Use the security incident documentation checklist and the camera evidence export checklist when video is involved.
Document the blind spots
- physical keys and copied keys;
- inside thumb-turn actions the model does not identify;
- offline events that never sync;
- shared PINs or shared phone accounts;
- voice actions without speaker identity;
- door opening without a contact sensor;
- clock drift between lock, camera, and alarm;
- history removed by subscription or retention changes;
- events relabeled after a user is renamed or deleted; and
- administrator actions without a separate audit trail.
Pair the log with a controlled physical key process using the mechanical-key backup checklist.
Use a monthly access-log review
- confirm named users and schedules;
- remove expired guest and contractor credentials;
- check lock, bridge, phone, camera, and alarm time zones;
- generate one known test event;
- review failed attempts and unexplained remote actions;
- confirm retention and subscription settings;
- review administrators and active sessions;
- export one small test window and confirm it opens; and
- record failures, owner, correction, and retest date.
Repeat the full audit after a move, manager change, lost phone, account recovery, lock reset, bridge replacement, time change, integration change, or access incident.
Run a 60-minute smart-lock access-log acceptance test
- Minutes 0–10: inventory lock, bridge, accounts, integrations, users, schedules, keys, contact, camera, and alarm.
- Minutes 10–20: verify time zones and create known keypad, phone, remote, manual, and auto-lock events.
- Minutes 20–30: compare user labels, event types, timestamps, door state, and upstream automation records.
- Minutes 30–40: disconnect the bridge or internet, create a safe local event set, reconnect, and measure sync.
- Minutes 40–50: test a temporary user’s rename and revocation, then confirm the credential no longer works.
- Minutes 50–60: export a narrow incident packet, review permissions and retention, list blind spots, and assign corrections.
Keep the door attended, retain a working local fallback, and stop if the test could create a lockout or unsafe entry condition.
Do not approve the log until these blockers are cleared
- Regular users share one keypad PIN or account.
- The lock, camera, alarm, and export use unexplained time zones.
- An unlock event is being treated as proof that the door opened.
- The owner cannot explain what happens during an outage.
- A removed user can still unlock locally or through an integration.
- Former residents, workers, or contractors can view history.
- No one knows the retention period or incident-hold process.
- An export exposes unrelated household activity without approval.
- Physical-key entry is described as logged when the model does not record it.
- Audit failures have no owner or retest date.
Frequently asked questions
Does a smart-lock log prove who entered?
It proves only what the credential and event label support. A named PIN shows that PIN was accepted; it does not prove who used it or that the door opened.
Will a physical key appear in the history?
That depends on the lock. Some models record a generic manual action; others do not record key use. Test the installed model.
What happens when the internet is down?
Events may remain local, sync later, appear with upload time, or be absent. Run a controlled outage test rather than assuming.
Should I keep access logs forever?
No. Set retention around an approved need, privacy rules, lease or workplace terms, and local law. Preserve a narrow incident window when required.
Can I use the lock log instead of a door sensor?
No. Lock state and door state answer different questions. Use a named contact when you need open and close events.
How often should I audit the log?
Run a small monthly check and a full audit after user, account, device, network, time-zone, integration, or incident changes.
Bottom line
A smart-lock history is useful when every label has an owner, every timestamp has a known time zone, outages are tested, viewers are limited, retention is defined, and blind spots are written down. Test the record before an incident, pair it with door state and controlled keys, and preserve only the evidence you are allowed to keep.