If someone may have accessed your alarm, camera, lock, or smart-home account, treat it as both a digital-security incident and a property-access incident. Preserve evidence, protect people, contain access, rotate recovery and credentials in the right order, inspect devices and automations, then test the entire alarm path. Do not start by factory-resetting everything; that can destroy useful records and make recovery harder.
Account compromise response at a glance
| Stage | Action | Do not |
|---|---|---|
| Safety | Move to a safe place and use emergency services when there is an immediate threat | Enter or confront someone to verify an alert |
| Preserve | Record times, alerts, emails, users, devices, clips, and changes | Delete accounts, clips, or logs in panic |
| Contain | Secure email, carrier, password manager, vendor account, recovery, and sessions | Change only the visible app password |
| Physical access | Rotate alarm codes, lock credentials, mobile keys, and temporary access | Assume a password change removed a door credential |
| Recover | Audit members, devices, integrations, automations, cameras, monitoring, and network | Restore an old backup without checking its access |
| Validate | Run alarm, camera, lock, internet, power, and recovery tests | Declare success because the app opens |
1. Protect people first
If there is evidence of a break-in, stalking, domestic abuse, coercive control, an unlocked door, disabled alarm, or unknown person at the property, prioritize personal safety. Go to a safe location, contact emergency services when appropriate, and follow professional advice. Do not use a camera or lock app to provoke, confront, or trap a suspected intruder.
2. Decide what may be exposed
List the alarm account, camera account, lock account, smart-home platforms, router, Wi-Fi, email, mobile carrier, password manager, authenticator, cloud storage, voice assistant, installer portal, monitoring portal, and billing account. Record whether the suspected access could reveal the address, alarm state, schedules, live video, recordings, door codes, mobile keys, household members, phone numbers, or emergency contacts.
3. Preserve evidence before changing the system
- Write the first known and last known safe times.
- Save security emails, MFA prompts, password-reset notices, new-device alerts, and carrier messages.
- Capture user lists, trusted devices, active sessions, codes, automations, integrations, and device status.
- Export relevant event history and video without editing the originals.
- Photograph unexpected device changes, open panels, moved cameras, damaged sensors, or altered locks.
- Record support case numbers and advice.
Preserve records lawfully and minimize sharing. If the incident may involve crime, abuse, employment, tenancy, insurance, or litigation, ask the appropriate authority or adviser how to handle evidence.
4. Use a trusted device and network
Do not recover the system from a phone or computer that may itself be compromised. Use a patched device you control, preferably on a known network or cellular connection. Check for unknown profiles, remote-management tools, browser extensions, forwarding rules, and active sessions. If the home network is suspect, separate recovery from that network until the router and Wi-Fi are reviewed.
5. Secure the root accounts in order
- Primary email and its recovery methods.
- Mobile carrier account and SIM-transfer protections.
- Password manager and authenticator.
- Apple, Google, Amazon, or other smart-home platform accounts.
- Alarm, camera, lock, router, and monitoring accounts.
Use unique passwords, enable phishing-resistant MFA where available, regenerate backup codes, review recovery email and phone numbers, and revoke unknown sessions. Do not reuse the same new password across the stack.
6. Audit owners, members, and trusted devices
Review owner, administrator, resident, guest, caregiver, installer, landlord, property manager, vendor, and support roles. Remove unknown or unnecessary people. Revoke lost, sold, repaired, or old phones, tablets, browsers, watches, voice assistants, and TV devices. Confirm removed users cannot sign in, view cameras, unlock doors, disarm, change members, or alter billing.
7. Rotate alarm codes and duress credentials
Change master, household, guest, contractor, cleaner, installer, temporary, panic, and duress codes according to the provider’s instructions. Do not test panic, police, fire, medical, or duress functions without approved test mode and monitoring guidance. Check whether codes are shared across keypad, lock, garage, gate, or building systems and rotate each system separately.
8. Rotate every form of door access
| Credential | Containment | Validation |
|---|---|---|
| Mechanical key | Rekey or replace only when physical key exposure is credible and authorized | Test all approved keys and emergency access |
| Keypad code | Delete unknown and shared codes; issue named replacements | Old code fails, new code works, history is correct |
| Phone/watch key | Revoke old devices and wallet credentials | Removed device fails at the door |
| Fingerprint/card/fob | Delete unknown templates or credentials | Revoked credential fails and approved users pass |
| Remote unlock | Review accounts, integrations, and automations | Only named users can unlock remotely |
9. Review cameras, microphones, and recordings
Check members, live-view history where available, downloaded clips, sharing links, storage, retention, privacy modes, audio, camera position, motion zones, and disabled/offline events. Rotate camera credentials and revoke sessions. Inspect whether cameras were moved or turned away. Avoid publishing or forwarding sensitive footage unnecessarily.
10. Inspect integrations and automations
Audit Apple Home, Google Home, Alexa, IFTTT, Matter bridges, Home Assistant, smart locks, garage doors, thermostats, lights, geofencing, webhooks, API tokens, and voice assistants. Remove unknown connections and rotate tokens where supported. Review routines that unlock, open, disarm, suppress alerts, change camera privacy, or depend on presence. Rebuild only the routines you can explain and test.
11. Check router, Wi-Fi, and local access
Change router administration and Wi-Fi credentials when exposure is credible. Update firmware, disable remote administration you do not need, review DNS and port forwarding, remove unknown clients, separate guest and IoT access where practical, and reconnect security devices deliberately. Document which devices fail after the credential change rather than leaving unknown equipment online.
12. Contact monitoring and support
Tell the alarm provider or monitoring service that account or access compromise is suspected. Verify account ownership, verbal password, duress process, monitoring contacts, call order, address, permits, test mode, and any recent support changes. Ask whether the provider can identify new devices, member changes, remote commands, failed sign-ins, or account recovery activity. Record the case number.
13. Inspect physical devices
Walk every hub, panel, keypad, sensor, camera, lock, siren, router, bridge, power supply, backup battery, and communication device. Look for opened covers, missing screws, moved mounts, unplugged cables, unknown USB devices, disabled tamper switches, swapped labels, reset indicators, and unexpected network connections. Photograph anomalies before repair.
14. Run recovery tests
| Test | Pass condition |
|---|---|
| Priority entry | Correct zone, delay, siren, alert, history, monitoring receipt, and response |
| Removed access | Old user, code, phone key, session, and integration fail |
| Camera evidence | Live view, recording, timestamp, storage, and export work day and night |
| Internet down | Local alarm and documented backup behavior match the design |
| AC power loss | Hub, communicator, router, cameras, locks, and siren meet measured runtime |
| Account recovery | Owner can recover without a revoked device or compromised contact |
15. Decide whether to reset or replace devices
Factory reset only after evidence preservation and account control are addressed. Follow the manufacturer’s sequence for removing ownership, unpairing, reset, firmware, re-enrollment, naming, permissions, and testing. Replace a device when ownership cannot be cleared, firmware is unsupported, tampering cannot be ruled out, or recovery depends on an untrusted account.
16. Watch for recurrence
For several weeks, review sign-ins, new-device notices, member changes, resets, lock history, disarms, camera offline events, integration changes, carrier activity, email forwarding, and billing changes. Keep alerts focused so unusual events are visible. Escalate repeated unauthorized access to the provider and relevant authorities.
Incident record
Document the timeline, affected accounts, devices, users, credentials, evidence locations, containment actions, support contacts, physical findings, tests, remaining risk, and next review date. Use the home-security documentation checklist, home cybersecurity guide, and phone replacement checklist to rebuild clean ownership.
Where Abode fits
For an Abode system, review named app users, account recovery, MFA, trusted phones, alarm codes, CUE automations, cameras, locks, integrations, monitoring contacts, plan status, and cellular backup. Use official support for account recovery or suspected unauthorized access. Compare the Smart Security Kit, Abode Cam 2, and current Abode plans.
FAQ
Should I factory-reset every security device immediately?
No. Protect people and accounts, preserve evidence, revoke access, and understand the scope first. Reset devices later when it supports a documented recovery plan.
Is changing the alarm-app password enough?
No. Review email, carrier, MFA, recovery, sessions, users, codes, locks, cameras, platforms, integrations, router access, and monitoring contacts.
What if a former partner or roommate still has access?
Prioritize safety, remove digital and physical credentials, document the change, and seek police, legal, tenancy, or domestic-abuse support where appropriate.
How do I know recovery worked?
Verify revoked access fails, priority alarm events complete the correct response path, cameras and locks work, failures match the design, and account recovery no longer depends on an exposed device or contact.
Turn containment into a 72-hour recovery retest
An account incident is not closed when the password changes or the app opens again. Recovery must prove that old access fails, root accounts are controlled, physical credentials are safe, monitoring and alerts reach the right people, cameras preserve evidence, integrations no longer expose tokens, and suspicious behavior does not return. Use a short containment test, a full acceptance test, and a 72-hour observation window.
| Recovery layer | Proof | Failure |
|---|---|---|
| Root identity | Email, carrier, password manager, MFA, and recovery belong to approved people | A reset still routes through an exposed phone, email, or former administrator |
| Sessions and members | Unknown users and devices are revoked and fail on their own test device | Only the visible member list was changed |
| Physical access | Old codes, keys, wallet credentials, and remote unlock paths fail | A password change leaves a door credential active |
| Automations and tokens | Every integration and key has an owner, job, scope, and rotation result | An old webhook or routine can still unlock, disarm, or suppress alerts |
| Evidence and alerts | Clips, timestamps, event history, and call delivery work after containment | Recovery silently breaks recording or sends alerts to the wrong person |
| Recurrence watch | New-device, recovery, member, code, and automation changes stay clean for 72 hours | Unexpected access or changes reappear without escalation |
Build a time-bounded incident timeline
Separate known facts from assumptions. Record the last known safe event, first suspicious event, discovery time, each account or physical change, evidence export, support contact, containment action, test, and recurrence check. Normalize time zones and note device clock errors. Use the incident timeline worksheet so email notices, alarm events, camera clips, carrier messages, and support records can be compared without overwriting the originals.
Do not copy passwords, recovery codes, alarm PINs, or private footage into a general incident note. Record credential labels, evidence locations, hashes where appropriate, access restrictions, and the person responsible for preservation.
Revoke sessions from the server side
A password change may not terminate every trusted browser, phone, TV, watch, voice assistant, installer portal, or application token. Work through the trusted-device and session audit. Capture the approved list, sign out unknown or unnecessary devices, rotate recovery material, and test an old device after refresh, restart, and attempted sign-in.
Check the owner’s own devices too. A sold phone, repair loaner, former browser profile, or shared tablet can remain a valid path even when no unknown username appears. Confirm session revocation separately for alarm, camera, lock, smart-home, email, carrier, password manager, and vendor support accounts.
Contain SIM-swap and recovery-channel risk
If unexpected carrier messages, loss of service, MFA failures, or password resets involve a phone number, use the SIM-swap response checklist. Contact the carrier through a trusted route, protect number transfer, secure voicemail, rotate exposed recovery paths, and inspect financial and email accounts that relied on the same number.
Do not move every account to a new phone number before controlling the email and password manager that can change it again. Build two independent owner recovery paths that do not depend on the same device, number, or household member.
Rotate webhooks, API keys, and hidden integrations
List IFTTT, Home Assistant, Apple Home, Google Home, Alexa, Matter bridges, voice assistants, webhooks, API keys, installer tools, property-management services, and scripts. Use the webhook and API-key audit to document owner, purpose, scope, creation date, last use, secret location, rotation action, and rollback.
Revoke unknown tokens before recreating needed rules. Rebuild one integration at a time and prove its intended action plus one action it must not perform. Pay special attention to routines that unlock, open, disarm, disable cameras, mute notifications, change presence, or create new users.
Remove camera shares and prove evidence access
Review every live-view role, household member, guest, export link, shared album, recorder login, cloud session, and support access. The camera shared-user access audit separates viewing, exports, talk, settings, deletion, and invitation permissions. Remove a test user, then confirm access fails on that person’s own phone rather than only checking the owner screen.
Export one post-recovery clip and open it on another device. Verify camera name, timestamp, event start, audio choice, retention, and file readability. Record any gap created during password changes, network work, camera restart, account transfer, or storage reconfiguration.
Retest monitoring call delivery and verbal identity
Coordinate test mode with the provider before triggering monitored events. Use the monitoring call-delivery test to check caller ID, spam filters, Focus modes, voicemail, primary and backup contacts, call order, and escalation. Separately verify verbal passwords, duress procedures, address, permits, and contact ownership through an authenticated support route.
Do not test police, fire, medical, panic, or duress functions outside the provider’s approved process. The goal is to prove communication and account identity without causing a false dispatch or exposing a secret in shared notes.
Reconcile digital recovery with physical access
Test each old alarm code, keypad code, phone key, wallet key, fingerprint, card, fob, mechanical key, garage credential, and remote-unlock path. A revoked app member can still know a shared code or hold a physical key. Issue named replacements, preserve required emergency egress, and follow lease, employment, or ownership rules before removing access.
For each priority opening, trigger a real sensor event under approved test conditions. Confirm zone name, entry delay, alarm mode, local siren, app notification, event history, monitoring receipt where selected, and safe household response.
Run a 60-minute post-compromise acceptance test
- Confirm immediate safety, evidence preservation, incident owner, trusted recovery device, and the accounts and properties in scope.
- Verify email, carrier, password manager, MFA, backup codes, and recovery destinations through independent paths.
- Review every member and session; revoke one test device and prove it cannot reconnect locally or remotely.
- Test old alarm, lock, wallet, card, biometric, remote-unlock, and mechanical credentials according to the physical-access plan.
- Open each priority entry under test mode; confirm zone, delay, siren, alerts, history, monitoring receipt, and response.
- Export one camera clip, verify timestamp and identity, then remove one test viewer and confirm live and recorded access fail.
- Rotate or remove one test integration or token; prove the intended rule works and a prohibited unlock, disarm, or mute action does not.
- Disconnect broadband without cutting local power; record alarm, camera, lock, app, alert, monitoring, and recovery behavior.
- Run the approved monitoring call-delivery check on primary and backup phones.
- Recover the owner account without using a revoked device or exposed contact.
- Review router clients, remote administration, DNS, port forwarding, guest or IoT isolation, and device reconnection.
- Record remaining risk, owners, deadlines, next recurrence checks, and the condition for professional escalation.
Pass: exposed paths fail, approved users and physical credentials work, root recovery is independent, priority alarm events complete the documented response path, evidence remains usable, integrations have named scope, outages match the design, and recurrence checks are clean. Fail: an old session, user, code, key, viewer, token, or recovery channel remains; a priority alarm or clip fails; support identity is unclear; or suspicious changes return.
72-hour recurrence watch
- At 2 hours: check new-device notices, sign-ins, members, sessions, recovery changes, camera shares, codes, automations, carrier messages, and email forwarding.
- At 24 hours: repeat priority entry, notification, camera export, old-user failure, and account-recovery checks.
- At 48 hours: inspect router clients, vendor support cases, billing changes, monitoring contacts, and any unexpected offline or reset event.
- At 72 hours: close only if the evidence record is complete, all owners accept the residual risk, no suspicious access has returned, and future review dates are assigned.
Escalation blockers
- There is an immediate safety, stalking, abuse, burglary, or coercive-control risk.
- The owner cannot control the root email, carrier, password manager, MFA, or recovery path.
- A former or unknown user retains digital or physical access.
- Evidence may be needed for police, legal, tenancy, insurance, employment, or abuse support.
- A vendor cannot confirm ownership, session revocation, device transfer, or support activity.
- Alarm, camera, lock, monitoring, network, or recovery behavior cannot be explained after containment.
- Suspicious sign-ins, member changes, resets, disarms, camera access, or carrier events recur during the watch window.