A failed smart-lock attempt is a state to investigate, not a complete incident report. It can mean a mistyped or expired code, the wrong door, a jammed bolt, low battery, an app or account fault, a removed user, or an intentional access attempt. The installed system must show what happened, keep the physical door safe, notify the right people, and provide a tested recovery route.
Start with the exact lock’s current vendor manual and support record. Keep model, firmware, settings, users, event history, owner, recovery, and changes in the system documentation checklist and change log. Use the access-code audit for named credentials, the installation acceptance test for physical faults, and the battery and outage checklist for recovery.
Prove the physical door and lock before testing denials
| Baseline | Record | Pass condition |
|---|---|---|
| Door geometry | Door thickness, backset, handing, frame, strike, latch, bolt throw, alignment, seals, closer, sag, weather, and seasonal movement | The bolt reaches the intended state without pulling or pushing the door |
| Lock hardware | Exact model, firmware, keypad, reader, thumb turn, cylinder, motor, clutch, tamper state, emergency power where supported, and physical key | Twenty ordinary lock-unlock cycles pass before denial testing begins |
| Power | Battery type, installation date, measured state, warning threshold, warning path, replacement access, disposal, and retest | Low power is visible before the access job silently fails |
| Controller | Direct radio, bridge, hub, Wi-Fi, router, app, account, remote path, clock, offline state, stale state, and reconnect order | A software state is not mistaken for the physical bolt state |
| Safety | Emergency egress, fire-door limits, accessibility, occupants, manual override, lockout response, and local responder | Testing never blocks approved egress or emergency action |
Write the exact attempt-counting and lockout policy
| Policy field | Capture for the exact model | Test result |
|---|---|---|
| What counts | Wrong PIN, incomplete entry, repeated key, expired code, disabled code, wrong schedule, app denial, mobile credential denial, fingerprint failure, key-card failure, and tamper event | Each approved test creates the expected distinct state |
| Counting window | Number of attempts, time window, per-code or per-lock counting, reset after success, keypad timeout, and clock source | The observed count matches the saved setting or vendor record |
| Lockout | Start condition, duration, keypad behavior, local sound or light, physical lock state, app state, local control, remote control, and extension after more attempts | The door stays in the intended physical state and the lockout ends as documented |
| Notification | Local warning, push, email, text or service path where offered, recipients, delay, grouping, acknowledgment, escalation, and quiet modes | Primary and backup people receive enough context to act |
| History | Timestamp, time zone, door, device, credential label, result, battery, network state, user visibility, retention, export, deletion, and owner | The owner can distinguish tested denials from ordinary successful access |
| Recovery | Wait, local administrator, second administrator, physical key, emergency power where supported, battery replacement, support, reset, and proof after recovery | The owner restores approved access without weakening the lock or sharing an owner credential |
Separate wrong code, expired access, jam, battery, network, and account faults
Run each state separately. A wrong code should not look identical to a bolt that could not move. An expired contractor code should not be reactivated because the owner assumed the battery failed. An app that cannot reach the lock should not report a fresh physical state. Record the keypad feedback, physical bolt, door contact, lock event, battery, bridge or hub, network, app, account, alarm mode, camera state, alert, history, and recovery owner.
- Wrong or incomplete code: verify counting, feedback, history, alert threshold, lockout, and successful access after the documented end.
- Expired or disabled code: verify denial at the physical door and confirm no app, household, alarm, automation, service, or recovery right remains.
- Jammed bolt or misaligned door: inspect physical fit before resetting software or increasing motor attempts. Repeated motor strain is not an access-policy fix.
- Low or removed battery: record warning lead time, keypad and app state, physical key or emergency-power path where supported, replacement, clock, and history.
- Bridge, hub, internet, or app loss: record local keypad behavior, physical state, stale remote state, alert loss, queued events, clock, reconnect order, and gaps.
- Account or administrator fault: verify the owner, signed-in devices, second administrator, recovery methods, support case, and former-user removal before changing the lock.
Map failed attempts to the door sensor, alarm, camera, and responder
For every selected test, record the physical keypad action, lock denial, bolt state, door contact, alarm mode, local warning, camera trigger, first useful frame, recording, app alert, event history, named human action, and outcome. A denied code does not prove the door remained closed. A camera clip does not prove which credential was entered. A door contact does not prove the bolt was locked. Keep those records separate and join them by door, timestamp, and test ID.
Write the household response before enabling alerts. A single mistype during an approved visit may need no escalation. Repeated denials at an empty property, a disabled former-user code, a door-open event after denial, or a camera event at the same time may require a different safe response. Do not ask an untrained person to confront someone or create an unapproved emergency call.
Test alert delivery, grouping, quiet modes, and escalation
- Record the physical attempt time from a trusted clock and the lock’s displayed or exported timestamp.
- Measure keypad feedback, first local warning, first remote alert, grouped alert, repeated alert, acknowledgment, second-owner receipt, and escalation.
- Repeat an approved test while the primary phone is locked, in a Focus or quiet mode, offline, and unavailable. Record what reaches the backup person.
- Check whether alerts reveal a live code, full address, guest identity, camera view, or other data beyond what the response job needs.
- Correct clock, time-zone, user-label, door-name, or recipient faults and repeat the complete path.
Remove users without destroying the incident record
After an approved former-user or compromised-code test, revoke the named code, mobile credential, app share, household membership, alarm code, lock integration, automation, installer role, signed-in session, service access, and recovery method. Collect physical keys, fobs, cards, remotes, and lockbox access. Preserve only lawful records needed for support, property management, or an incident, with an owner and deletion date.
Prove the former credential fails at the physical door, then have the current owner and second administrator pass lock, alarm, evidence, support, and recovery checks. Do not clear the full event history or factory-reset the lock before required evidence, configuration, and ownership records are saved.
Recover from lockout without weakening access control
| Recovery route | Required record | Unsafe shortcut |
|---|---|---|
| Wait for documented lockout end | Start, expected end, physical state, occupants, safe waiting location, owner, and successful approved credential after expiry | Repeated attempts that extend the fault or hide the original sequence |
| Physical key | Key owner, storage, access route, cylinder state, door sensor, alarm action, return, and audit | Untracked spare keys shared with workers or neighbours |
| Second administrator | Named person, separate account, exact rights, identity check, action, history, and post-recovery audit | Sharing the primary owner’s password or recovery code |
| Battery or emergency power | Exact supported method, safe access, battery state, temporary power, physical result, replacement, and retest | Assuming a method shown for another model applies |
| Vendor support or locksmith | Identity, case, authorization, remote-access limit, physical-work scope, changes, keys, codes, account rights, and closeout | Leaving installer, support, code, key, or recovery access active |
| Reset or replacement | Owner approval, saved records, alarm and automation impact, physical security during downtime, transfer, pairing, users, deletion, disposal, and full acceptance | Resetting first and discovering later that ownership or evidence was lost |
45-minute failed-attempt and lockout acceptance test
- Minutes 0-7: reconcile door fit, exact lock, firmware, power, bridge or hub, apps, accounts, users, attempt policy, alerts, history, alarm, cameras, responders, and recovery routes.
- Minutes 7-17: run approved valid, wrong, incomplete, early, late, expired, and disabled credential events; record physical state, count, feedback, history, alerts, and lockout.
- Minutes 17-25: inspect door contact, alarm mode, camera evidence, timestamps, primary and backup notifications, acknowledgment, and named response for selected denials.
- Minutes 25-34: run one approved jam, battery, bridge, hub, internet, or primary-phone failure; record distinct fault states, local jobs, stale states, clocks, gaps, and restoration.
- Minutes 34-41: revoke a temporary credential, prove former physical and digital access fails, and have the second administrator complete the approved recovery path.
- Minutes 41-45: sign attempt policy, physical state, alerts, history, privacy, user removal, recovery, support, rollback, maintenance, and next-test records.
FAQ
What should a smart lock do after repeated wrong codes?
The answer depends on the exact model and settings. Save the current vendor record, then test attempt counting, keypad feedback, temporary lockout, local and remote alerts, physical lock state, event history, recovery, and reset without creating an unsafe egress or owner lockout.
Does a failed smart-lock attempt prove someone tried to break in?
No. It can come from a mistyped code, expired guest, wrong door, child, cleaner, contractor, keypad fault, low battery, jammed bolt, account problem, or hostile attempt. Record the physical and digital evidence before assigning intent.
Should the owner clear a smart-lock lockout remotely?
Only through the approved recovery process for the exact property. Confirm the person, physical door, alarm state, camera privacy, event history, local conditions, and safe fallback before changing access or clearing a fault.
How should smart-lock failed-attempt alerts be tested?
Use approved non-emergency tests with named codes and times. Measure keypad feedback, attempt count, lockout start and end, local and remote alerts, history, alarm and camera state, second-owner receipt, recovery, and restoration.
