Washington Requires a Non-App Key Option for Smart Locks, Starting 2027

A landlord doesn't have to rip out an existing smart lock system by default; the obligation is to provide the non-biometric, non-app alternative when a tenant actually asks for one.

[Cite: ESSB 5937, 2026 Wash. Sess. Laws, c. 55, Sec. 2]

That request-triggered structure means a landlord can keep operating an app-based system as the default access method for tenants who are fine with it, while still needing a ready process, a spare key, a programmable fob, standing by for any tenant who prefers not to use the app or doesn't want biometric data collected at all.

The statute lists key fobs, key cards, physical keys, and keypads using a manually entered coded sequence as acceptable alternatives.

[Cite: ESSB 5937, Sec. 2]

That specificity gives a landlord a clear compliance menu rather than a vague standard to interpret; a landlord evaluating which alternative to stock can pick from this list with confidence, rather than guessing whether some other access method might or might not satisfy the requirement.

The required privacy policy has to cover the data elements collected, the safeguards protecting that data, retention schedules, breach-notification protocols, data destruction or anonymization procedures, and how temporary guest access gets authorized.

[Cite: ESSB 5937, Sec. 3]

That's a genuinely detailed disclosure, closer to a standalone privacy document than a lease addendum paragraph; a landlord using a vendor-supplied smart lock system should check whether the vendor already produces documentation covering each of these specific elements, rather than trying to draft all of it from scratch.

The privacy policy has to go out at lease signing for a new tenancy, or within 5 days of installing the system for an existing tenancy.

[Cite: ESSB 5937, Sec. 3]

A landlord installing a new smart access system in an already-occupied building faces a real deadline, 5 days, that starts running the moment the system goes in; waiting until a tenant complains or asks about the new locks isn't a safe compliance strategy under that timing structure.

The statute defines a specific, closed list of data a smart access system may collect: name, unit number, contact preference, biometric data if used, hardware identifiers, credentials, lease dates, and security-purpose access timestamps.

[Cite: ESSB 5937, Sec. 4]

A landlord or a smart-lock vendor configuring system settings should treat this list as the maximum scope of data collection allowed, not a starting point; a system defaulting to collect additional data, location history beyond entry logs, say, or marketing-related information, would exceed what this statute permits regardless of whether a tenant technically consented through a lease signature.

Biometric data appears on the permitted-collection list only "if applicable," meaning only when the system actually uses a biometric method like a fingerprint or facial scan for access.

[Cite: ESSB 5937, Sec. 4]

A landlord choosing a biometric-capable system takes on a correspondingly higher compliance bar; the alternative-access requirement specifically exists to give tenants a way to avoid that biometric data collection entirely, so a landlord relying heavily on biometric-only access without a readily available non-biometric option is building in unnecessary exposure.

The statute allows collecting the time and method of access only for security and operational purposes.

[Cite: ESSB 5937, Sec. 4]

That purpose limitation matters beyond just what data exists; a landlord using access-log data for something outside security or operations, building a tenant behavior profile for marketing purposes, for instance, would be using permitted data for an impermissible purpose, even if the data collection itself fell within the statutory list.

A keypad relying solely on a manually entered coded sequence, with no app and no biometric feature, isn't the kind of system driving this law's alternative-access and privacy-policy requirements in the same way an app-based or biometric system is.

[Cite: ESSB 5937, Sec. 2]

A landlord using only this simpler kind of system should still review the statute's exact scope language carefully, since the alternative-access requirement is framed around systems that use biometric data or an app specifically; a landlord already using a plain keypad likely has a lighter compliance lift than one running an app-based system, but shouldn't assume total exemption without confirming against the statute's actual text.

Since a landlord is on the hook for providing the privacy policy and honoring access requests regardless of which vendor's hardware or software is installed, a landlord needs to confirm the vendor's own documentation and system settings actually support compliance, rather than assuming the vendor has already built this in.

[Cite: ESSB 5937, Secs. 2-4]

A landlord renewing or signing a new smart-lock vendor contract ahead of the January 2027 effective date should specifically ask the vendor whether its system supports a non-app access method, whether its data collection can be configured to the statutory list, and whether it can supply privacy-policy content covering every required element.

Since the obligation to provide a non-app alternative is triggered by a tenant's request, a landlord benefits from keeping a clear record of when a request came in and when the alternative access method was actually provided.

[Cite: ESSB 5937, Sec. 2]

A landlord who can show the date a tenant asked for a physical key or keypad code, and the date that alternative was actually handed over, is in a much stronger position if a tenant later claims the request was ignored or delayed unreasonably.

The practical starting point is inventorying every property using an app-based or biometric smart access system and confirming each vendor's system can actually produce the required privacy-policy content and support a non-app alternative.

Building a standard request-and-fulfillment process, a documented intake step when a tenant asks for an alternative access method, and a tracked installation-to-disclosure timeline for any new system, keeps compliance consistent across a portfolio rather than handled ad hoc property by property.