Editorial scope: This is an operating audit for households that connect alarms, cameras, locks, lights, hubs, voice assistants, dashboards, or notification services through webhooks, API keys, long-lived tokens, automation platforms, or custom scripts. It does not recommend bypassing a vendor’s supported controls. Product features and integration methods change, so verify every step against current first-party documentation.
Why home-security automation secrets need their own audit
A webhook URL, API key, bearer token, integration password, or long-lived access token can authorize software to read events or control devices. It may expose camera state, alarm mode, lock state, household presence, or an automation action. These secrets are not ordinary configuration text. Treat them as credentials with an owner, purpose, scope, storage location, expiry decision, rotation method, and revocation test.
A password-manager audit answers how people store and recover credentials. A network-segmentation guide answers how devices communicate. This audit answers a narrower question: which machine credential lets which integration do what, and can the household find, rotate, and revoke it without breaking security?
Start with a complete integration inventory
List every automation path, including old experiments. Search automation platforms, hub dashboards, phone shortcuts, scripts, NAS devices, home servers, code repositories, notes, password managers, spreadsheets, email, chat history, and cloud dashboards. A secret that is forgotten but remains valid is still an access path.
| Field | Record | Reason |
|---|---|---|
| Integration name | Plain-language job and owner | Stops an opaque token from outliving its purpose |
| Source and destination | Service, hub, device group, or script at each end | Shows where an event or command crosses systems |
| Credential type | Webhook URL, API key, OAuth grant, service account, or token | Determines rotation and revocation method |
| Permissions | Read events, view cameras, change modes, control locks, or administer | Exposes excessive scope |
| Storage | Secret manager, vault, environment file, hub, or cloud platform | Finds copies that need protection or deletion |
| Created/last used | Date, known automation, and latest confirmed event | Identifies abandoned credentials |
| Revocation path | Exact menu, command, or support process | Makes incident response possible |
| Fallback | Manual arming, local key, native app, or named responder | Prevents unsafe dependence on the integration |
Classify the security consequence
Do not rate every automation equally. A token that turns on a decorative light is different from one that unlocks a door, disarms an alarm, retrieves camera clips, or reveals when residents leave. Assign a consequence tier based on the strongest action or most sensitive data available through the credential.
- Tier 1 — context only: low-sensitivity state such as a non-security light. Still inventory and revoke it when unused.
- Tier 2 — household pattern: occupancy, schedules, device names, or general alarm state.
- Tier 3 — evidence or security state: camera images, event history, sensor state, alarm mode, or notification routing.
- Tier 4 — physical control or administration: unlock, open, disarm, delete evidence, add users, create credentials, or change recovery settings.
Tier 3 and Tier 4 credentials need a named owner, protected storage, documented rotation, independent revocation, and a tested manual fallback. Avoid granting administrative scope merely because it is easier during setup.
Use least privilege and separate jobs
Create a different credential for each integration when the platform permits it. Do not reuse one high-privilege token across dashboards, scripts, notifications, and experiments. Separate read-only event access from physical control. Separate a production automation from development or testing. If one script only needs to read a door contact, it should not also be able to unlock the door or add users.
Record whether the platform supports named applications, scopes, service accounts, OAuth grants, expiry, IP restrictions, callback allowlists, or read-only roles. If it exposes only an all-powerful permanent token, write that limitation into the risk record and reduce its distribution.
Store secrets outside scripts and screenshots
Do not paste a live secret directly into a public code repository, shared document, screenshot, support ticket, or household chat. A webhook URL can contain the credential in the URL itself. Redacting only a visible account name may leave the secret usable.
- Use the automation platform’s supported secret store, a controlled password manager, or an operating-system credential store.
- Keep configuration files containing secrets outside version control and verify ignore rules before the first commit.
- Remove secrets from logs, error messages, screenshots, exported diagnostics, and copied browser history where practical.
- Do not put the property address, device map, recovery codes, lock PINs, and API secrets in one broadly shared document.
- When a contractor needs access, create a separate short-lived credential and revoke it at handoff.
The OWASP Secrets Management Cheat Sheet provides general secret-lifecycle practices. The home-security password manager and recovery-code audit covers household vault roles and emergency release.
Audit webhook-specific risks
A webhook often receives a request at a hard-to-guess URL. Secrecy of that URL may be part of the protection, but obscurity alone is not a complete control. Record whether the receiver checks a signature, shared secret, timestamp, replay window, source, method, content type, and expected payload. Reject unexpected commands and fields.
For an outgoing webhook, record what data leaves the home-security system. A harmless-looking event may reveal device names, room names, alarm state, timestamps, household routines, or a camera reference. Send the smallest event needed. Avoid including lock codes, recovery data, full addresses, raw camera URLs, or unrestricted device identifiers.
Test replay behavior in a safe sandbox or with a non-destructive action. A captured request should not be able to unlock, open, or disarm repeatedly. Never test a live physical-control webhook in a way that could create unsafe access.
Audit API keys and long-lived tokens
For each key or token, confirm who created it, which account owns it, its visible name, permissions, creation date, last-used information, expiry, and revocation route. A token tied to a former resident’s personal account is not acceptable production ownership.
Where a platform supports OAuth or a named application grant, record the connected app and granted scopes. Removing a user from the household may not revoke every app grant or token they created. Check both the security platform and the external automation service.
Home Assistant documents its current authentication model and long-lived access tokens in its authentication API documentation. Use current first-party documentation for the platform actually installed; do not assume another platform behaves the same way.
Logging without leaking the credential
A useful log records the integration name, event type, result, timestamp, and correlation or request identifier. It should not print the full secret, authorization header, signed URL, lock code, camera URL, or raw personal data. Review logs from both sides of the integration because one service may retain more than the other.
Define a retention period. Keep enough history to investigate failures and unauthorized actions, but do not retain sensitive household patterns indefinitely without a reason. Restrict log viewers and exports. Test whether deleting an integration also removes its stored logs, queued actions, and cached credentials.
Rotation plan
- Create the replacement credential with the smallest required scope.
- Update one integration copy at a time and confirm it uses the new credential.
- Run a non-destructive event and verify the expected log on both sides.
- Revoke the old credential.
- Confirm the old credential fails and does not remain in another automation node or backup.
- Delete obsolete copies from approved storage, configuration, notes, and deployment systems.
- Record the rotation date, operator, evidence, defect, and next review.
Do not call a rotation complete while the old key still works. If the platform cannot overlap old and new credentials, schedule a controlled maintenance window and keep the native app or manual security path available.
Revocation and compromise response
Revoke immediately if a credential appears in a public repository, public screenshot, misdirected message, exposed backup, lost device, unknown automation, unexpected log entry, or former user’s possession. Assume the secret was copied even if the original file is deleted.
- Preserve the minimum evidence needed: integration name, time, affected scope, and safe log references.
- Disable or revoke the exposed credential through the authoritative platform.
- Stop or isolate the affected automation without disabling direct alarm sensing or safe exit.
- Check users, app grants, lock codes, alarm modes, camera exports, and deleted or changed settings.
- Create a clean replacement only after the storage and ownership problem is fixed.
- Test physical state, notifications, evidence, manual fallback, and backup response.
Use the account-compromise response checklist for the wider household account and device response.
Keep automation subordinate to direct security state
A webhook or custom script should not become the only record that a protected door opened, the only way to arm, or the only route for an urgent alarm notification. Direct sensors, native alarm logic, and the supported monitoring path should continue to perform their documented jobs when the automation server is offline.
Do not automatically unlock or disarm from an unauthenticated webhook, weak presence signal, camera classification, or a single phone location. The smart-home automation failure test covers trigger/action collisions and rollback. The geofence arming audit covers multi-resident presence failure.
Failure matrix
| Failure | Expected safe state | Evidence to capture | Fallback owner |
|---|---|---|---|
| Webhook receiver offline | Direct sensing and native alarms continue; no destructive queued replay | Failed request and recovery timestamp | System owner |
| Token revoked | Integration fails visibly; native app and manual control remain | Unauthorized response without secret content | Integration owner |
| Automation server compromised | Tier 4 controls can be revoked independently | Token inventory and last-used records | Primary administrator |
| Internet unavailable | Local direct security behavior matches the written plan | Sensor, siren, lock, recording, and alert results | Local responder |
| Former user remains | All personal and machine credentials can be removed | User, app-grant, token, code, and device audit | Household owner |
45-minute webhook and API-key acceptance test
- Minutes 0–5: list the integration, owner, source, destination, credential type, scope, storage, and physical consequence.
- Minutes 5–10: confirm the secret is absent from source code, screenshots, public repositories, ordinary logs, and broadly shared notes.
- Minutes 10–15: run one permitted non-destructive event and match source time, destination time, result, and correlation record.
- Minutes 15–20: send an invalid or expired test request through the supported safe method. Confirm denial is visible without exposing the secret.
- Minutes 20–25: disable the receiver or integration. Confirm direct sensors, native alarms, safe exit, and manual control continue as documented.
- Minutes 25–30: restore the integration and check that old queued physical-control commands do not replay unexpectedly.
- Minutes 30–35: create or identify a replacement credential, document the rotation path, and verify storage and least privilege.
- Minutes 35–40: revoke a designated test credential and confirm it fails everywhere it was copied.
- Minutes 40–45: verify backup-owner access, update the change record, remove test artifacts, and assign defects and retest dates.
Pass only when every production credential has a named owner and purpose, permissions match the job, approved storage is known, logs omit the secret, rotation and revocation are documented, revoked test access fails, direct security remains safe during integration failure, and a backup operator can recover without the primary person’s device.
Quarterly review and change triggers
Review the inventory quarterly and after a resident, contractor, phone, hub, automation server, router, account owner, monitoring plan, or integration changes. Review immediately after a repository exposure, unexpected physical action, unexplained alert failure, vendor breach notice, or lost administrator device.
Use the home-security change log to record the operator, reason, before/after state, test evidence, and rollback. Use the app permission audit to review the human viewers and operators around each integration.
FAQ
Is a webhook URL a password?
If possession of the URL authorizes an event or command, treat the full URL as a credential. Do not publish or casually share it.
Should one API key be reused for every automation?
No. Separate jobs where the platform allows it, grant the smallest scope, and revoke one integration without breaking unrelated automations.
Does removing a household user revoke their integrations?
Not necessarily. Check users, connected applications, OAuth grants, service accounts, long-lived tokens, webhooks, lock codes, and copies stored on external platforms.
How often should machine credentials be reviewed?
Review quarterly, after any owner or system change, and immediately after suspected exposure or unexplained automation behavior.
Can a custom automation replace native alarm logic?
It should not be the only path for direct sensing, safe exit, arming, urgent notification, or monitored response. Test native and manual fallbacks with the automation offline.
