Connected Safe Privacy: A Practical Threat Model

The Privacy Threat Model for a Connected Safe

A connected safe protects two assets: the property inside and the information created around that property.

Camera views, access times, user identities, failed attempts, location, movement, temporary codes, recovery answers, notifications, and device status can reveal where valuables are kept and when they are available. That data deserves the same deliberate threat model as the enclosure.

The goal is not to assume a hidden vulnerability. It is to map what is known, what is claimed, what remains unverified, and which controls a buyer should require.

Begin with the assets

The obvious asset is the safe's contents. The digital system can create several others.

Video may show the room, the interior, a person, or the stored property. An access log can show routines and authorized users. Location and network records can identify the site. Notifications can reveal that a valuable object is being protected. Recovery answers and account details can open other routes. Device and software state can help an attacker choose timing or technique.

The access-control system is also an asset. Credentials, biometric templates, device keys, session tokens, temporary codes, recovery processes, and signing keys all influence who can observe or change the safe.

Map the trust boundaries

The system crosses boundaries whenever data or authority moves between parties or devices.

flowchart TD
    A["Safe, sensors, cameras, and local storage"] <--> B["Home or business network"]
    B <--> C["Vendor cloud and service providers"]
    C <--> D["Primary user's app and account"]
    C <--> E["Shared or temporary user"]
    C --> F["Notification and messaging services"]
    G["Vendor support and administrators"] --> C
    H["Update build and signing systems"] --> A
    I["Law enforcement, hotel, buyer, or successor"] -. request or transfer .-> C

Each arrow needs authentication, authorization, encryption, logging, retention, revocation, and an owner. The dotted path represents disclosure or transfer conditions, not continuous access.

The threat model should include the phone, email account, mobile platform, network, cloud providers, support staff, update system, and future corporate owner. Protecting only the device account is not enough.

The current SPACE policy permits broad collection

SPACE's privacy policy is version 1.1, effective March 26, 2023. It names Oh Baby LLC, doing business as SPACE.

The policy says the service may collect voice and video recordings, photographs, device location, opening and closing times, user identity, device movement, software updates, screen activity, settings, failed PIN attempts, avatars, phone numbers, uploaded images, connected mobile devices, and recovery answers. It says recordings are generally kept locally and in the cloud.

The policy also includes wallet, banking, blockchain, and transaction language that may be broader than the safe product or may reflect an older service design. A policy describes allowed handling. It does not establish that every listed field is collected by every current unit.

The correct next step is a current product-specific data map, not an accusation.

Cameras change both visibility and exposure

The current Space App page says users can view live camera feeds inside and outside the safe. The product page describes two cameras and optional recording storage.

Cameras can help distinguish cleaning, authorized access, and tampering. They can also record household members, workers, guests, customers, hotel occupants, private documents, or the valuables themselves.

The buyer should know when recording starts, what indicator appears, whether audio is included, whether local and cloud copies differ, who can initiate live view, whether support can access footage, how shared users are limited, how long recordings remain, and what deletion removes.

People who may be recorded also need appropriate notice and treatment under applicable law. A safe's location does not make every recording use lawful or expected.

Activity history can become a behavioral map

The app page says the activity log records successful and unsuccessful access and identifies the user. This can create accountability when several people share a location.

The same log can reveal routines. Regular opening times may suggest business operations, travel, medication schedules, cash handling, or occupancy. Failed attempts may reveal a conflict or a compromised credential. Temperature and humidity history can hint at location or stored-material sensitivity.

Data minimization asks whether every field is needed, at what precision, for how long, and by whom. A useful recent activity record does not automatically justify indefinite vendor retention.

NIST IR 8425 includes data protection, logical access, interface control, software update, and product cybersecurity information within its consumer IoT outcomes. Those outcomes apply across the product, not just the safe.

Account recovery can bypass strong local controls

A buyer may enable a strong PIN, fingerprint, and second factor at the device while leaving email or phone recovery weak.

Review every recovery route. Can email reset the account? Can a support agent change ownership? Can a lost phone session be revoked? What proof transfers a used safe to a new owner? What happens after a death, business closure, divorce, employee departure, property sale, or hotel checkout?

The privacy policy says users select personal questions for PIN recovery. Security questions can rely on information known to family members or discoverable elsewhere. A current design should explain how those answers are protected and whether stronger recovery is available.

Recovery needs a visible record. The owner should know when credentials, ownership, or recovery methods change.

Shared and temporary access need lifecycle controls

SPACE describes separate users and a temporary PIN that lasts five minutes and can be issued once per 24 hours.

Temporary access reduces the need to disclose a permanent credential. It does not remove the need to verify who received the code, which actions it permits, whether it can be forwarded, what the cameras record, and how the event appears in the log.

Longer-lived shared users need expiration and revocation. Removing an app user should also invalidate cached sessions, local permissions, notification access, camera access, and any related recovery role.

Organizations need role separation. A person who can review activity may not need to open the safe. A support operator may need diagnostics without camera footage. A hotel administrator may need fleet status without access to guest content.

Updates and vendor access belong in the privacy model

Software updates can change collection, retention, providers, permissions, and available controls. The update system therefore has indirect power over privacy.

NIST SP 800-193 emphasizes protection, detection, and recovery for firmware. A trusted update path helps prevent unauthorized software from changing device behavior.

The vendor also needs a clear internal access model. Which employees or contractors can see account records, logs, footage, diagnostics, or update status? Are support actions approved and logged? What changes during an acquisition or service-provider switch?

The SPACE policy says data may be disclosed during a sale, merger, reorganization, or similar transaction. That is common policy language, but it makes deletion and export rights relevant before a corporate event occurs.

Emergency and notification paths expose more systems

Notifications may pass through mobile platforms, push providers, SMS services, email systems, or emergency-message routes. Each service can receive metadata and create another delivery dependency.

The Space App page says its emergency text function is still being tested nationally. SPACE's terms say text 911 and panic PIN features are not monitored.

That limitation belongs in the security and privacy review. A user may reveal an incident to more systems without receiving a guaranteed response.

Turn the threat model into vendor questions

Ask for a current data-flow diagram, subprocessor list, encryption design, retention schedule, deletion process, camera-access model, biometric-template location, account-recovery controls, support-access logs, incident-notification policy, vulnerability-reporting route, update-support period, ownership-transfer process, and end-of-life plan.

Then test necessity. If remote viewing is not needed, can it remain disabled without breaking local security? If cloud recording is not needed, can recordings stay local? If a shared user only needs access, can camera viewing be withheld? If the app disappears, does local access remain dependable?

The safest configuration is not always every feature turned on. It is the smallest set of connected functions that serves the actual threat.

The [[How to Evaluate a Smart Safe Before Buying One|smart-safe buyer guide]] places this privacy review alongside physical rating, anchoring, fallback, power, support, and vendor continuity.

AI assisted with research organization and drafting. Dalton Anderson remains responsible for the threat model, source boundaries, and publication decision.