Guest access should default to least privilege with an explicit expiry

What it is

Guests — a friend staying the week, the weekly cleaner, a rental guest, the neighbour feeding the cat — should receive access that is at creation minimal (only the devices and operations they need) and time-boxed (expires when the stay ends), as the default behaviour rather than something the owner remembers to clean up. Least privilege bounds the scope; the expiry bounds the lifetime; both belong to the granting moment, because that is when information peaks — the checkout date is printed on the booking, the cleaner only comes Tuesday mornings.

The target is the common reality: guest grants are created quickly and forgotten quickly, and one instance of convenience becomes standing exposure.

Why it happens

Why must defaults carry this, rather than the owner's memory?

The granting moment is the information peak. Purpose, scope, and duration of a guest's visit are all present at grant time: checkout is in the booking, service hours in the arrangement. That information decays — three days later the owner no longer recalls which permissions were given; a month later even the "to whom" blurs. Deferring scope and lifetime decisions to later hands them to a moment with less information and weaker motivation.

Residual grants are invisible, accumulating risk. Once granted, an authorization has no presence in daily life — no notifications, no screen space, no functional footprint. Invisible objects don't get cleaned; each guest grant's residual probability is independent, and after several visits the home carries a batch of long-unused access rights nobody can enumerate.

Default stickiness. Users accept what the interface defaults to — the classic default effect. Default "permanent + whole-home" yields permanent whole-home access; default "time-boxed + scoped" yields convergent access from the same unthinking click. In systems like these, security properties are distributed mainly by defaults, not by user diligence.

Studying it

• Access-control preference studies: scenario questionnaires (what should the cleaner / visiting friend / rental guest get, for how long) show that respondents, prompted about scope and duration, overwhelmingly endorse least privilege — high support paired with low actual configuration rates shows the problem lives in default design, not willingness.
• Residual-grant audits: audit smart-lock authorization records on shared-accommodation platforms — count of credentials still valid after checkout, distribution of survival times. Residual-rate comparisons between "expires at checkout" and "valid until manual cleanup" defaults are this entry's direct evidence form.
• Controlled deployments: the same cohort of hosts and guests randomized into expiry-by-default versus permanent-by-default flows, tracking residual grants alongside wrongful lockouts (legitimate entries denied by premature expiry) — benefit and cost measured together.

One methodological caution: rental guests and personal-visit guests carry different semantics (commercial versus personal relationships); findings do not transfer freely between the two — studies must state their scene, and products must design the defaults separately.

Where it stops holding

• Recurring guests need standing but narrowed access. For a weekly cleaner, per-visit time-boxing manufactures friction — the correct minimization there is "long-lived, extremely narrow" (the lock only, Tuesday mornings only). Minimize the scope, not necessarily the lifetime.
• The entry channel determines feasibility. App-install-and-register flows for guests are costly (a separate problem); many scenarios run on lock keypad codes — the code is the credential, and both expiry and scope ride on it. Systems without per-person credential channels cannot offer "least privilege" at all, only all-or-nothing.
• Minimality is capped by the system's expressiveness. Where the only options are "add as family member" or "nothing", this advice cannot land — it presupposes at least guest-level independent credentials.

Applying it

• Make scope and expiry required fields in the grant form, pre-filled from context: bookings auto-fill checkout dates; selecting "cleaner" auto-fills service hours.
• Restrict scope options to the small set guests need — entry and necessary devices; camera playback and administrative actions never enter the default set.
• Give the owner a pre-expiry warning ("Zhang's lock access expires tomorrow") with one-tap extension — when guests stay longer, extending must be cheaper than re-granting.
• How to check: audit "guest credentials still valid 30 days after the stay ends" periodically, targeting zero; monitor the rate of legitimate-entry denials (over-tight expiry) at the same time — both indicators together prevent winding the clock too far down.

Related

• Same group: Z4.08.2 After expiry, access must revoke automatically · Z4.08.3 Guest actions need distinct records from family members' · Z4.08.4 Over-complicated granting makes owners share the master account
• Nearby: Z2.04 Presence and identity · Z6.04 Non-users present
• Search terms: least privilege · temporary access · guest access control · smart lock