After expiry, access must revoke automatically

What it is

Authorizations should have lifetimes, and the lifetime should be enforced by the system: expiry deactivates the credential without anyone remembering to press "revoke". Making revocation a manual step converts the designer's job into the user's to-do item — a to-do with no reminder, no visibility, and no deadline, which predictably never gets done.

This entry and default time-boxing at creation are adjacent halves: that one governs scope and lifetime at the granting moment; this one governs the enforcement mechanism at lifetime's end — why collection must be automatic, and which edges automatic collection must handle.

Why it happens

Why does manual revocation fail structurally? Three independently sufficient reasons.

No triggering event. The revocation task never enters the human queue: a guest leaving produces no system event (unless the grant hangs off an external anchor), so nothing pulls the owner's attention back to it. Tasks without triggers run purely on random recollection — which is why residual authorizations survive for months.

The object is invisible. An active guest credential occupies no daily attention — no notifications, no display, no interference — and "out of sight, out of mind" is attention's default law. Manual revocation demands standing vigilance over a long-invisible object.

Social cost blocks execution. Revoking a specific person is a social act — "removing a friend's access" reads as ending the friendship. Even long after the relationship has faded, active retraction crosses an awkward threshold and is deferred indefinitely. Automatic expiry removes that layer: the system collects by rule, not the owner against someone — "your code expired" is vastly easier to live with than "I deleted you". The mechanism here performs a social-semantic translation.

The correct form of automatic collection follows: expiry triggered by system clock or external anchor (booking checkout, calendar event), credential invalidation producing a record (when, whom, which grant), with revocation depending on no one's action.

Where it stops holding

• Hard cutoffs are hostile at the edges. Delayed flights, guests staying later — a lockout at 12:00 sharp executes the rule as malice. Automatic collection requires grace periods and one-tap extension: at expiry, narrow the door (owner confirmation required) rather than slam it; extension must be a three-second phone action, or owners will hand out permanent access to avoid the hassle.
• Shared credentials escape the model entirely. If the guest holds the same PIN the owner uses, expiry has nothing to revoke — changing the password kicks everyone off, including the owner, so nobody changes it. One credential per person is the precondition for automatic revocation; keypad codes especially must be issued per person.
• Anchor quality defines revocation semantics. Expiry tied to a booking follows the booking (a changed checkout slides automatically); a bare timestamp drifts from reality until manually corrected. Take the external anchor whenever one exists.

Applying it

• Bind expiry to external anchors wherever possible: bookings, calendar events, reservation systems; when the anchor changes, the authorization follows.
• Issue codes per person, never a shared PIN: keypad codes, one-time links, NFC tags all work — independent credentials give collection something to act on.
• Expiry events are recorded and visible: "Zhang's lock access expires today at 12:00" enters the household activity feed, making collection at least inspectable as it happens.
• Remind the owner 24 hours before expiry with one-tap extension attached — grace is not laxity; it reduces exception-handling to one click.
• How to check: a penetration audit — after a batch of completed stays, test whether those credentials still work; residual rate should be zero. Track lockout complaints at the same time (the over-tight-grace signal). Both numbers healthy is automatic revocation actually holding.

Related

• Same group: Z4.08.1 Guest access should default to least privilege with an explicit expiry · Z4.08.3 Guest actions need distinct records from family members' · Z4.08.4 Over-complicated granting makes owners share the master account
• Nearby: Z4.07 Multiple users and permission allocation · Z2.04 Presence and identity
• Search terms: auto-revoke · access expiry · temporary credentials · smart lock