An unknown unlock attempt is an incident, not just an app notification. The first job is to protect people and avoid confrontation. The second is to decide whether the alert came from a mistyped code, an old user, a compromised account, a failing lock, door movement, or physical tampering. This checklist covers immediate response, direct door checks, codes, phones, household access, logs, cameras, alarms, evidence, recovery, and a 45-minute acceptance test.
Do not assume a “failed code” alert proves someone is outside. Do not assume a “locked” status proves the door is secure. App labels can be delayed, incomplete, or wrong. Use several independent facts: direct door state, lock state, camera view, alarm events, household location, credential history, and a safe physical check by an authorized person.
Smart lock failed-entry response at a glance
| Signal | Immediate question | Safer action |
|---|---|---|
| Unknown code attempt | Is a person present and is the code tied to a real user? | Keep the door secured, contact household members through a trusted route, and review named credentials |
| Repeated failures | Is this a person, a stuck keypad, a child, weather, or automation? | Use camera and direct door facts; do not remotely unlock to “test” for an unidentified person |
| Tamper alert | Is the lock, keypad, cylinder, door, strike, or sensor physically disturbed? | Move people to safety, use emergency help when warranted, preserve evidence, and avoid touching the entry area |
| Remote unlock in history | Which account, phone, session, integration, or automation performed it? | Revoke access through a known-safe device and verify every connected account separately |
| Door open while lock says locked | Did the bolt extend against an open or misaligned door? | Treat direct door state as the higher-priority fact and arrange a safe physical check |
| No camera or log | Is evidence missing because the device, network, storage, plan, clock, or account failed? | Preserve what remains, record the gap, and do not invent a cause |
1. Protect people before investigating the app
If anyone may be in immediate danger, move to a safer location and contact local emergency services. Do not approach an unknown person at the door merely to confirm a notification. Do not stand behind a glass panel, announce that the home is empty, or reveal a hidden key, alarm code, camera blind spot, or resident schedule.
Call or message household members through a trusted contact route. Ask whether anyone used the lock, shared a code, scheduled a visitor, delivered a key, changed a battery, moved the door, or triggered an automation. Avoid posting the incident in a shared group that might include former residents, guests, contractors, or an account under review.
If the event appears to be physical tampering or attempted entry, preserve the area. Do not reset the lock, wipe the keypad, move damaged hardware, delete camera clips, or repair the door until safety, police, building-management, or insurance needs are understood.
2. Build a timeline from independent facts
Record the alert exactly as shown, including time, device name, event type, user or code label, phone that received it, and any event identifier. Note the phone’s time zone and whether its clock is automatic. Then collect the lock log, contact-sensor history, alarm events, camera footage, doorbell events, garage or gate history, network state, and household messages.
Use a simple table:
| Time | Source | Observed fact | Confidence and gap |
|---|---|---|---|
| Event time | Lock app | Failed credential, unlock, lock, jam, tamper, battery, or offline event | Record whether the event is local, cloud-delayed, user-labelled, or unattributed |
| Same minute | Door sensor | Open, closed, or no change | Check sensor alignment and whether history is complete |
| Before and after | Camera | Approach, person, vehicle, package, door movement, or no visible activity | Record field-of-view limits, clip start, audio, and missing seconds |
| Same period | Alarm | Entry delay, alarm, bypass, mode change, or no event | Confirm the door belongs to the expected zone and mode |
| Same period | Network and account | Offline device, login, session, password change, invited user, or automation run | Do not infer a login when the record only says “remote” |
Keep facts separate from theories. “The lock recorded three failed attempts” is a fact. “A former contractor tried to enter” is a theory until a named credential, camera, witness, or other evidence supports it.
3. Check direct door and lock state safely
A lock motor can report success even when the door is ajar or the bolt stopped against the strike. A contact sensor can report closed while the door is not fully latched. If a safe authorized person can inspect the entry, check from a protected position and avoid disturbing damage.
- Confirm whether the door is open, closed, latched, and physically locked.
- Look for damage to the keypad, escutcheon, cylinder, handle, latch, deadbolt, strike, frame, hinges, glass, wiring, and contact sensor.
- Photograph the whole doorway before close-ups when evidence may matter.
- Do not force a jammed motor repeatedly.
- Check whether weather, door sag, loose hinges, a tight seal, or a shifted strike explains a jam without dismissing the security alert.
- Keep a working mechanical entry and emergency-exit path for authorized residents.
The smart lock physical security audit covers the door, bolt, strike, cylinder, and a full test. Use the door-alignment guide only after incident evidence is preserved.
4. Identify the exact credential or control route
List every way the lock can be controlled: physical key, keypad master code, resident code, guest code, fingerprint, phone app, Apple Home, voice assistant, alarm app, delivery service, automation platform, building system, garage app, remote support, and API connection. The lock-maker account and Apple Home household may have different users and logs.
Do not settle for a generic label such as “guest,” “owner,” or “remote.” Match the event to a named person, device, account, or integration. Ask:
- Was the code unique to one person?
- Was it active at the event time?
- Could another person know it?
- Was it reused on another lock, alarm, phone, or building keypad?
- Was the person expected at the property?
- Was the event a failure, successful unlock, relock, mode change, or automation?
- Does the lock log identify the source reliably, or only show a broad route?
Use the smart lock access-code audit to review owners, residents, cleaners, carers, guests, contractors, schedules, master credentials, and deletion.
5. Review household members and former access
Check current and former residents, family, cleaners, dog walkers, carers, landlords, property managers, tradespeople, installers, guests, delivery workers, emergency contacts, and building staff. A person removed from Apple Home may still have a lock code, vendor-app session, alarm user, camera share, garage account, voice access, old phone, watch, tablet, key fob, or physical key.
Apple’s Home sharing guidance explains current member and guest controls. Apple’s Personal Safety User Guide is a useful starting point when personal safety and account sharing overlap. Follow current guidance for the specific account and software; do not assume one removal closes every vendor path.
If a person should no longer have access, remove them from each system separately and record the result. The HomeKit member-removal checklist provides a wider offboarding path.
6. Secure accounts from a known-safe device
If account compromise is possible, use a trusted device and trusted network. Change the lock-maker password, Apple Account password, alarm password, camera password, delivery-platform password, primary email password, and any reused credential as needed. Turn on multi-factor authentication where supported. Review recovery email, phone numbers, trusted devices, passkeys, security keys, app passwords, and connected services.
Do not change every setting from a phone that may be lost, shared, remotely managed, or under review. Do not send new passwords or codes through a compromised email or group chat. If the only owner account may be compromised, contact the vendor through its official support route and preserve ownership records, serial numbers, receipts, and account identifiers.
Review sessions and devices before ending them so the timeline is not lost. Record device names, model, software, approximate location, last activity, and whether the session is recognized. Then revoke unknown or unnecessary sessions. Use the trusted-device and session audit for the full account path.
7. Disable risky automations without losing direct security
Pause any rule that can unlock or disarm based on presence, geofence, voice, camera classification, delivery status, NFC tag, button, web request, or another platform while the incident is investigated. Keep direct entry sensors, local siren, smoke and carbon-monoxide alarms, leak alerts, panic controls, and safe manual locking available.
Record the automation before disabling it: trigger, conditions, action, account owner, integration, last run, and affected devices. Otherwise, a useful timeline can disappear. Check for duplicate rules in Apple Home, the lock app, alarm app, voice assistant, delivery platform, and third-party automation service.
Avoid creating a new “temporary” rule that unlocks more broadly during the response. Use an authenticated manual path and a named person. The home-security automation checklist covers safe triggers, direct state, conflicts, and failures.
8. Preserve camera, alarm, and lock evidence
Export the original event when the service permits it. Preserve the full clip before and after the alert, not only a screenshot or cropped social-media copy. Record the source account, camera, timestamp, time zone, retention period, export date, file name, and person who handled it. Keep an unchanged original and work from a copy.
Capture lock and alarm logs in the same period. If the app only provides screenshots, include the screen that identifies the device and date. Do not alter timestamps or claim a video shows an unlock when it only shows a person near the door.
Check whether a plan change, expired subscription, full local card, disconnected recorder, camera privacy mode, offline hub, weak Wi-Fi, power loss, wrong clock, or removed user created an evidence gap. Document the gap. The HomeKit camera evidence export checklist covers recording assignments, retention, export, and verification.
9. Decide whether to involve police, building staff, or insurance
Contact emergency services when there is an immediate threat, forced entry, active tampering, or another condition that warrants urgent help. For a past event, follow local non-emergency reporting guidance. Give facts: time, address, direct observations, event records, visible damage, and preserved footage. Do not confront or publicly identify a person based only on an app label.
Tenants should follow lease and building rules for doors, keys, locks, cameras, shared entrances, and repairs. Notify the landlord or property manager when required, but do not send master passwords or personal account recovery details. Record who owns the damaged hardware and who authorizes repair.
For an insurance claim, preserve receipts, serial numbers, installation records, photographs, repair estimates, police information, inventory, video, and account logs. Ask the insurer what evidence and timing it requires. The home-security insurance claim evidence checklist covers the broader claim record.
10. Replace or rekey only after evidence is preserved
Physical damage, unknown key control, exposed master credentials, a compromised cylinder, unreliable electronics, or an owner-account dispute may require rekeying or replacement. Do not factory-reset the lock first if the reset could erase logs or ownership evidence.
Before replacement, record the model, serial number, firmware, battery, bridge or hub, door dimensions, backset, handing, strike, key count, code list, account owner, integrations, and incident state. Photograph wiring and hardware placement. After replacement, remove the old device from the lock app, Apple Home, alarm, voice assistant, automations, router, delivery service, and maintenance records.
Keep emergency egress working during repair. The smart lock retrofit guide covers door type, backset, thickness, clearance, and rental rules.
11. Restore only named minimum access
Rebuild access from zero rather than importing every old guest. Keep one owner, a backup owner where supported, named residents, and only the temporary users needed now. Give each user the minimum schedule and door. Avoid a shared household code.
| Role | Typical need | Do not grant by default |
|---|---|---|
| Owner | Device ownership, recovery, code administration, logs | Shared password or unrecorded backup owner |
| Resident | Named entry, lock status, needed alerts | Other-user management, camera exports, billing, master reset |
| Child or dependent | Simple named entry and emergency exit | Remote guest creation, alarm master control, household administration |
| Cleaner, carer, contractor | One door during a fixed schedule | Permanent owner access, unrelated cameras, whole-home disarm |
| Guest | Short scheduled access | Reusable generic code, logs, settings, remote household control |
| Installer or support | Time-bounded diagnostic access when required | Standing account, personal password, unnecessary video access |
12. Reconnect smart-home and alarm paths carefully
After the physical lock and owner account are stable, reconnect Apple Home, the alarm, voice assistant, camera, delivery service, and automations one at a time. Test after each connection. If an unknown event returns, the last connection narrows the cause.
For Abode users, confirm the exact lock and hub route against the current Abode Lock page and Abode HomeKit information. Use a direct door sensor such as the current Mini Door/Window Sensor where appropriate, and check the plans page for current service behavior. Verify exact compatibility, logs, alerts, automations, monitoring, and plan dependencies rather than carrying an old setup assumption into the recovered system.
13. Run the 45-minute smart lock incident recovery test
- Minutes 0–5: ownership. Confirm the lock owner, backup contact, trusted phone, recovery route, model, serial number, and physical key path.
- Minutes 5–10: door. Open, close, latch, lock, and pull-test the door several times without pushing or lifting it. Confirm the contact sensor follows direct state.
- Minutes 10–15: credentials. Test each retained named code. Confirm removed, expired, generic, and incident-related codes fail.
- Minutes 15–20: remote routes. Test the lock app, Apple Home, alarm app, and only the integrations that should remain. Verify unknown sessions and former users cannot act.
- Minutes 20–25: alarm. Test entry delay, zone name, Home, Away, Standby or equivalent modes, local siren, alerts, and monitoring test process when applicable.
- Minutes 25–30: camera and logs. Create a known test attempt and confirm the correct timestamp, source label, camera event, door event, lock event, export, and retention path.
- Minutes 30–35: automations. Restore one safe routine at a time. Confirm no camera, voice, presence, delivery, or geofence event can unlock or disarm by itself.
- Minutes 35–40: failures. Test the phone on cellular data and the documented lock-battery, Wi-Fi, internet, hub, camera, and service-ended fallback without causing a lockout.
- Minutes 40–45: outside rejection. From outside, attempt a removed code and an unauthorized route. Confirm failure, correct alerting, direct locked state, and a safe household response.
14. Do not close the incident until these blockers are cleared
- The household cannot confirm whether the door is physically closed and locked.
- An unknown successful unlock, user, session, code, key, phone, or automation remains unexplained.
- The only owner or recovery route is on a lost, shared, or suspect device.
- A former resident, guest, contractor, installer, or property manager still has unnecessary access.
- A generic code is shared across people or reused on the alarm and lock.
- Camera, lock, or alarm evidence needed for police, insurance, or building review has not been preserved.
- The door binds, the bolt misses the strike, the keypad is damaged, or the lock reports a state that conflicts with direct inspection.
- An automation can unlock or disarm from a single weak signal.
- Emergency exit depends on a phone, app, cloud, network, or battery path.
- The recovery test has not proved that removed access fails from outside.
15. Maintain an incident-ready record
Keep a protected record of lock models, serial numbers, receipts, installation dates, owner accounts, recovery contacts, code owners, physical keys, batteries, bridges, hubs, integrations, alarm zones, camera assignments, storage, monitoring contacts, emergency routes, support links, and the last test date. Do not store full passwords, master codes, or recovery keys in an unprotected document.
Review access monthly in busy shared homes and after every move, breakup, staffing change, lost phone, repair, account alert, plan change, hub replacement, router change, or suspicious event. Run a smaller outside rejection test after each change.
FAQ
Does a failed smart lock code mean someone tried to break in?
Not necessarily. It can come from a mistyped or old code, a legitimate user, keypad trouble, weather, door movement, or an unidentified person. Treat it as an incident and compare direct door, camera, alarm, credential, and account facts.
Should I remotely unlock the door to see who is there?
No. Keep the door secured, use safe camera or intercom checks, contact expected visitors through a trusted route, and use emergency help when warranted.
Can I factory-reset the lock after a tamper alert?
Preserve logs, photos, video, account records, and any police, building, or insurance evidence first. A reset may erase useful information and does not repair a damaged door or compromised key.
Does removing someone from Apple Home remove their lock code?
Not necessarily. Review Apple Home, the lock-maker app, alarm, camera, delivery platform, voice assistant, sessions, old devices, and physical credentials separately.
What proves the smart lock is secure after recovery?
Use direct closed-door state, full bolt travel, an outside pull test, named retained credentials, rejected removed credentials, correct logs and alerts, safe egress, and tested outage behavior.
