A HomeKit household-presence rule should change security behavior only when the right people have actually left or returned. One phone going offline, one resident leaving, or one stale location should not make an occupied home look empty. This audit maps the people, phones, Home hubs, Home and Away consumers, privacy limits, fallback controls, and failure tests needed before presence drives cameras, lights, locks, or alarm routines.
Apple’s current Home scenes and automations guide describes automations triggered when people arrive or leave. Its current Home sharing guide covers inviting and removing residents and controlling remote access. Use those pages as current starting points, then verify the exact behavior on every resident’s supported device, Apple Account, Home hub, network, and software version.
HomeKit household-presence audit at a glance
| Control | Question | Evidence | Failure test |
|---|---|---|---|
| Resident list | Whose departure and arrival should affect the home? | Named Home residents and accepted dates | Add and remove a safe test resident |
| Resident device | Which phone is the person’s presence source? | Named phone, account, settings and owner | Phone off, signed out, offline or replaced |
| Home boundary | What real arrival or departure should count? | Repeated entry and exit times at the property | Drive past, walk nearby, leave by another route |
| Home hub | Which hub runs remote and automation paths? | Active and standby hub record | Primary hub or its network path unavailable |
| Consumers | What changes when everyone leaves or someone returns? | Device-by-device Home and Away table | One resident stays, guest enters, person returns early |
| Manual fallback | How can the household correct the state safely? | Keypad, app, physical key, local control and owner | Primary phone and internet unavailable |
Start with people, not automations
List every owner, resident, child with control, caregiver, regular guest, house sitter, installer, shared tablet, and former resident. Only a person who should affect the occupied state belongs in the presence rule. A cleaner’s scheduled code, a visitor’s temporary access, or a wall tablet should not silently become evidence that the household is home.
| Person | Home role | Presence device | Should affect state? | Fallback |
|---|---|---|---|---|
| Primary owner | Owner and recovery | Named daily phone | Yes | Local alarm and physical entry |
| Resident | Daily control | Named daily phone | Usually yes | Named code and backup contact |
| Child or dependent | Minimum required control | Only if reliable and agreed | Document the decision | Caregiver and local entry |
| Guest or cleaner | Scheduled access | None by default | No | Temporary code and resident contact |
| Shared tablet | Fixed household control | Not a person | No | Locked-down local control |
Use the HomeKit member-removal checklist when a resident leaves. Remove Apple Home access, vendor accounts, alarm users, lock codes, camera shares, trusted sessions, voice assistants, monitoring contacts, recovery routes, and physical keys separately. Then prove the old phone and credentials fail.
Make a resident-device record
For each person who should affect presence, record the exact phone, Apple Account, Home membership, device name, normal connection, location permission state, cellular access, battery owner, low-power behavior, operating-system update owner, and replacement plan. Do not use “Luis’s iPhone” or “roommate phone” if multiple devices or people could match the label.
Run the HomeKit signed-out phone test on one safe device while another verified owner path remains. Record what happens to Home access, arrival and departure behavior, alerts, cameras, locks, account recovery, and cached access. A signed-out phone should not be able to leave the household in an unknown security state.
Define the Home and Away states device by device
“Home” and “Away” are labels until each device has an accepted behavior. Use the HomeKit Away-mode checklist to record the intended state for locks, contact sensors, alarm modes, cameras, lights, sirens, notifications, and optional response.
| Consumer | When someone is home | When everyone is away | Manual correction |
|---|---|---|---|
| Alarm | Accepted occupied mode or disarmed state | Accepted Away mode only after exit checks | Keypad, app or other approved local control |
| Entry sensors | Named state and alerts | Armed response and open-zone rule | Inspect, restore or bypass through the approved process |
| Cameras | Agreed streaming, recording and alert state | Agreed Away recording and alerts | Apple Home and vendor-app owners |
| Locks | Normal local access | No unsafe auto-lock assumption | Physical key or tested local fallback |
| Lights | Convenience only | Narrow deterrence schedule where useful | Switch and app control |
| Notifications | Useful occupied-state signals | Actionable Away events and maintenance warnings | Named primary and backup recipients |
Do not let a presence rule silence a smoke or carbon-monoxide warning, automatically unlock a door, bypass an unexplained open zone, erase evidence, or cancel a response event. Presence may help select a mode, but local entry, local warning, safe cancellation, and emergency action need explicit controls.
Separate camera recording from presence detection
A presence rule can select a camera state, but it does not prove the camera recorded. Use the HomeKit camera recording-options audit to test streaming, recording, event filters, notifications, storage, playback, export, and vendor-app settings for both When Home and When Away.
Run four two-person transitions: one leaves while one remains, both leave at different times, one returns while one remains away, and both return by different routes. Confirm that an occupied home does not switch to an intrusive recording state and that an empty home does not stay in a privacy-limited occupied state.
Activity zones answer a different question. The HomeKit camera activity-zone audit checks where motion should count, not whether the household is home. Walk zone edges separately after each accepted Home and Away transition.
Test the property boundary from real routes
Use the normal front door, garage, lift, stairwell, side gate, driveway, transit stop, and parking route. Record when the person actually leaves the property and when the state changes. Repeat arrival from each normal direction. A boundary that works only from one route is not ready for a security decision.
- Leave by the main route and continue beyond the normal nearby stopping point.
- Leave by the secondary route and travel in the opposite direction.
- Walk or drive past the property without entering. Confirm that a false arrival does not start a security change.
- Return but remain outside the door or gate. Record whether the state changes before the person is ready to enter.
- Enter while another resident remains away. Confirm that occupied settings return without removing the absent resident’s access.
Do not publish exact household routes, routines, or boundary screenshots to people who do not need them. Presence history can reveal when residents leave, return, work, travel, or sleep.
Prove the Home hub path
Record every eligible Home hub, its room, network connection, power path, software-update owner, and observed role. The Home hub redundancy guide covers placement, power, network, takeover, remote access, automation behavior, and recovery.
Test with the normal primary hub unavailable only when safe. Confirm the arrival and departure trigger, remote control, camera behavior, notifications, and automations. A second hub shown in the Home app is not proof that it will preserve every security path.
Test common false-Home and false-Away failures
| Failure | Risk | Test | Accepted fallback |
|---|---|---|---|
| One resident leaves | Occupied home switches to Away | Resident A leaves while B remains | State stays occupied |
| Phone battery dies | Resident disappears from the presence set | Safe test phone unavailable | Manual state and local access remain |
| Location unavailable | State becomes stale or wrong | Remove permission on a test device | Clear warning and manual correction |
| Phone replaced | Old phone remains trusted or new phone never counts | Documented replacement handoff | Old route removed; new route tested |
| Internet or hub loss | Remote and automation paths stop | Approved outage test | Local alarm, entry and manual mode work |
| Drive-by arrival | Home switches early | Pass the boundary without entering | No unsafe unlock or disarm action |
| Former resident | Old phone still changes the home | Removal and off-site test | No access or presence effect |
Make notifications part of the audit
The presence state is useful only if the household can detect and correct a bad transition. Use the HomeKit notification reliability checklist to test two residents, mobile data, Focus modes, locked phones, app permissions, repeat events, and outages.
Choose a narrow transition record: state before, person, device, route, trigger time, state after, affected alarm or camera mode, notification recipients, manual correction, and result. Avoid constant location alerts that create noise without an action.
Handle guests, caregivers and house sitters explicitly
A person who needs entry does not automatically need to affect household presence. Give scheduled access, the minimum Home role, or a named vendor-app role for the required dates. State which cameras and history are visible, who receives their entry event, and who removes access.
If a house sitter should temporarily count as an occupant, document the start, end, device, accepted Home and Away behavior, recovery contact, and removal test. Do not leave a temporary person in the permanent presence set because the visit ended successfully.
Protect privacy and recovery
Presence data can expose routines and occupancy. Limit resident, automation, camera, account and history access to people who need it. Use named accounts, the strongest authentication offered, safe recovery material, and a second verified owner. Do not share one Apple Account or one vendor password to make presence appear simpler.
Record the manual fallback before testing: physical key, keypad or local control, alarm cancellation method, camera privacy owner, router contact, hub location, and support path. The household should be able to enter and place the security system in a safe known state without relying on one phone.
Use change control after the first pass
Repeat the relevant tests after a resident joins or leaves, phone or Apple Account changes, Home hub changes, router or Wi-Fi changes, camera moves, lock changes, alarm modes change, a new vendor app is connected, or a major software update installs. The HomeKit security maintenance checklist helps assign monthly, seasonal and annual owners.
Keep the last accepted configuration, test date, known exceptions, and rollback step. Change one presence consumer at a time. If a camera rule changes, do not change the alarm and lock rules in the same test window.
Run a 60-minute HomeKit household-presence audit
- Minutes 0–8: record residents, roles, dates, phones, accounts, Home hubs, manual fallbacks and presence consumers.
- Minutes 8–16: test one resident leaving while another remains. Confirm the occupied alarm, camera, lock, light and notification states.
- Minutes 16–24: have both residents leave by different routes and times. Record the final departure trigger and every consumer that changes.
- Minutes 24–32: return one resident, then the second. Include an approach that passes near the property without entering.
- Minutes 32–40: make one safe test phone unavailable, signed out or location-limited. Prove the manual mode, local entry, owner recovery and warning path.
- Minutes 40–48: test camera recording, notification and activity-zone behavior in the accepted Home and Away states.
- Minutes 48–54: test the approved Home hub or internet failure path. Confirm local alarm and entry remain safe.
- Minutes 54–60: remove a safe test resident, prove old access and presence effects end, restore service, assign blockers and set the next review.
Do not enable presence-driven security until these blockers are cleared
- The household cannot name every person and phone that affects Home and Away state.
- One resident leaving can switch an occupied home to Away behavior.
- A drive-by, nearby stop or stale device can cause an unsafe arrival or departure action.
- Camera recording changes without resident agreement, privacy boundaries or a separate recording test.
- A presence rule can unlock a door, silence life-safety warning, bypass a zone, erase evidence or cancel response.
- No local entry, alarm control or manual state correction works when a phone, hub or internet path is unavailable.
- A former resident, old phone, guest, installer, shared account or trusted session still affects the home.
- No one owns hub health, phone changes, notification tests, access review, rollback or the next audit.
Frequently asked questions
Should every Home resident affect household presence?
No. Include only people whose real arrival and departure should change the accepted household state. Guests, cleaners, installers and fixed shared tablets usually need separate access rules.
Can presence automatically unlock the door?
A security-focused setup should not assume that a nearby phone proves a safe entry. Keep a deliberate local entry action and physical fallback, then test any convenience rule with strict conditions and rollback.
Does Away mode prove a camera is recording?
No. Test presence transition, camera recording, event filters, storage, playback, export and vendor-app settings as separate controls.
What is the most important two-person test?
Have one resident leave while another remains. The home should stay in the agreed occupied state, preserve local entry and alarm control, and avoid an intrusive camera or alarm change.
