Access logs the owner can request. Keys nobody hands over.

A smart lock's access-event history and device state are in scope under the Data Act. The cryptographic keys and access-control logic that keep the lock secure are not — and shouldn't be, since exposing them would defeat the lock's whole purpose. Building the access layer means drawing that line precisely.

See the security boundary Scope your lock API

Access history is data. The keys are security.

This is the central scoping question for any smart-lock access layer: which events happened is product data the owner can request; how the lock decides whether to open is the security mechanism Chapter II was never meant to expose.

Usually in scope

Access-event history: lock/unlock events, timestamps, which credential type was used
Battery and device state
Connectivity status
Firmware-update event log

Never exposed through this API

Cryptographic keys, PINs, or credential secrets
Access-control decision logic
Anything that would let a recipient bypass or clone lock access
Data never captured or retained by the lock's cloud

Field group	Typical source	Delivery format
Access-event history	Lock controller event log (credential type, not the credential itself)	Structured export, minimized and access-controlled
Battery/device state	Lock heartbeat via app sync	Status API for battery and connectivity
Connectivity status	Gateway/hub link log	Event export with signal quality and outage windows
Firmware-update log	OTA update service	Structured export of update history

The owner's right is live; security rules apply in parallel

The Data Act has applied generally since 12 September 2025. As a radio-connected device, a smart lock also sits within RED cybersecurity requirements that any new API has to respect.

Owner access-on-request

Provide an authenticated request path for access-event and device-state data already logged.

Owner-directed third-party sharing

Let an owner route non-credential lock data to a property-management platform they choose.

Pre-contract data transparency

Disclose what a new lock records and how it can be exported, before purchase.

Accessible by-design architecture

New lock platforms placed after 12 September 2026 should ship a scoped access API built in.

Build the door, not a hole in the wall

The access layer for a lock adds the same catalog, entitlement and audit machinery as any other connected product — with the security boundary drawn tighter, since the data itself reveals who entered a property and when.

Today: a closed loop

Product

Smart lock

Backend

Lock vendor cloud

Access-event history
Battery/device state
Connectivity status
Firmware-update log

Only exit

Manufacturer's own app

No user-facing export or API
No route for the user to authorize a third party
No permissions model, so every request is a one-off exception
No audit trail if a user or regulator asks what was shared

With a Data Act access layer

Product

Smart lock

Backend

Lock vendor cloud

Access-event history
Battery/device state
Connectivity status
Firmware-update log

New layer

Data Act access layer

Field catalog
User & device entitlements
Consent & grant registry

Customer export & portal

CSV/JSON, self-service, same quality as the manufacturer sees

Third-party API (OAuth)

Purpose-bound grant to a repairer, analytics or energy provider

Audit & compliance log

Request, decision, recipient and delivery evidence for review

What we implement, concretely

An access-log export API, a device-state API, scoped third-party sharing, and an audit layer that doubles as a security control.

Capability	What it does
Access-log export API	Authenticated access to non-credential access-event history per lock
Device-state & battery API	Status API for battery, connectivity and firmware state
Scoped third-party sharing	Purpose-bound, revocable access for a property-management platform the owner authorizes, strictly excluding credential fields
Security-grade audit layer	Owner/tenant-aware access control with a tamper-evident decision log

Draw the security boundary first

Confirm which fields are access data versus security mechanism, and enforce that split architecturally, not just by policy.

Model tenant/landlord/guest entitlements

Define time-boxed access for short-term guests and clean handoffs at move-in and move-out.

Design the owner API

Define catalog, request, third-party grant and delivery endpoints separate from the internal lock-control API.

Build the decision engine

Turn catalog, entitlement and privacy checks into explainable allow, partial and refuse outcomes.

Ship export and sharing

Deliver an owner export and a property-management sharing flow with revocable credentials.

Test the edge cases

Run through short-term rentals, disputed security-refusal claims and lost-device access revocation.

Smart lock Data Act FAQ

Must the lock's cryptographic keys or credentials ever be exposed through this API?

No, explicitly not. Chapter II gives users a right to product and related-service data, not to the security mechanisms that protect the product. Handing over keys, credentials or the access-control logic itself would defeat the lock's entire purpose and isn't what the Data Act asks for — the access layer should be architected so that path simply doesn't exist, not merely restricted by policy.

Is a landlord a different 'user' than the tenant currently living there?

Generally yes, and this needs an explicit handoff model. The tenant is the practical user of the access log and device state while they occupy the property; the landlord's interest is closer to the property and the device itself between tenancies. Build access entitlements to transfer cleanly at move-in and move-out rather than leaving both parties with standing access indefinitely.

Does access-event history count as sensitive personal data requiring extra GDPR care?

Treat it that way even if it doesn't formally fall into a GDPR special category. A record of who entered a home and when reveals presence patterns, visitor relationships and routines — genuinely sensitive information about people's private lives, deserving tighter minimization, retention and access controls than most other connected-product data.

Can a smart-lock vendor refuse a third-party integration request on security grounds?

Only through a specific, substantiated security justification, not as a blanket policy. The Data Act allows narrowly framed security restrictions where disclosure would risk serious adverse effects on legally defined health, safety or security requirements — but a vague 'security concern' used to block a legitimate property-management integration doesn't meet that bar and should be documented and challengeable.

How do short-term-rental access patterns complicate the 'user' definition?

A holiday-let property can have a property manager, an owner and a rotating series of short-term guests, each with a plausible but different claim to lock data. The practical answer is to scope access narrowly and by time window — a guest's entitlement to their own stay's access events, expiring automatically at checkout, with the property manager holding the standing operational relationship.

Is battery/device-health data alone a lower-risk starting point for a first API version?

Yes, and it's a sensible place to start. Battery level, connectivity and firmware-update status carry far less privacy risk than access-event history, so a first version limited to device-health data lets you build and test the entitlement and audit machinery before extending it to the more sensitive access-log fields.

Primary sources and status

Reviewed 9 September 2026. The Data Act, GDPR and RED cybersecurity delegated regulation are binding EU law. The Commission FAQs are non-binding implementation guidance. Yarify's API contract, entitlement model and delivery sequence are engineering recommendations, not legal advice.