Smart Locks for Kos: Access Without a Front Desk

In a kos (an Indonesian boarding house) with no front desk, the lock makes every access decision, usually offline. Deleting a tenant in the app locks them out only once the lock learns about it, or once their PIN, card or phone pass expires. Buy locks that delete inside the lock, keep phone permissions short, and guard the lock's clock.

The tenant lifecycle and the choice between Bluetooth-only locks and gateways (small WiFi bridges that keep every lock online) are covered in smart door access for boarding houses. This piece is about what breaks when nobody sits at a desk to notice.

What does a front desk do that the lock now has to do?

A hotel receptionist handles four access jobs, mostly without thinking about them:

1. Knowing who is still allowed. A guest whose stay has ended doesn't get a new key card.
2. Taking keys back. Checkout means the old card stops working.
3. Knowing today's date. An expiry only means something if someone knows what day it is.
4. Keeping the book. Who was let in, by whom, and when.

In a kos without staff, all four jobs move into a battery-powered lock on each door, often with no internet link at all. A decent lock can do all four. Each one also has its own way of failing, and none of them appear in the brochure.

Why doesn't deleting a tenant always lock them out?

Because deleting a tenant in the app and deleting them in the lock are two separate events. How far apart they land depends on where the credential (the PIN, card or phone pass) lives.

Smart locks store access in one of two ways.

The list lives in the lock. PINs and cards are written into the lock's own memory, like a guest list taped inside the door. Removing a name means someone connects to that lock (standing at the door over Bluetooth, or through a gateway) and erases it. Once that happens, it's final.

The pass lives on the phone. The server gives the tenant's phone a digitally signed pass, something like a stamped visitor badge with an end date printed on it. The lock checks the stamp and the date. It has no list to consult. Deleting the tenant in the app stops the server from issuing new passes, but the pass already on the phone keeps working until its end date, because the lock never hears about the deletion.

In the second model, the maximum revocation delay can approach the pass's validity period; for an already-issued pass, it is the remaining validity. That isn't a theoretical concern:

• Researchers from UC San Diego, presenting at the USENIX WOOT security conference in August 2025, found that phone passes ("access profiles") for the Master Lock D1000 deadbolt were valid for nine months, with revocation enforced only inside the app. A former guest who had copied their profile could keep opening the door until it expired. The vendor, notified on 10 March 2025, planned to cut validity to seven days.
• CERT/CC, the vulnerability coordination center at Carnegie Mellon University, published advisory VU#949046 on 7 March 2024. It covers locks built on Sciener firmware (the software inside the lock) and the TTLock app used to manage them. One of its CVEs (public IDs for security flaws), CVE-2023-6960, describes a virtual key that disappears from the app after deletion while it stays valid inside the lock. CERT/CC received no vendor statement, and the only workaround it offered was disabling Bluetooth functions.
• Earlier studies from 2016 to 2019, summarized in the same WOOT paper, found five lock products that let a revoked guest keep entering by putting their phone in airplane mode.

The in-lock list has a price: removing someone means a trip to the door, or a gateway on every floor. For a kos with a caretaker on site, that trip takes minutes. That's the trade I recommend for most kos: a deletion that is final at the door beats a remote deletion the lock never receives. Where gateways do earn their cost is laid out in one smart lock platform, two very different buildings.

Before ordering thirty locks, test one. Create a test PIN and a test phone key, delete both in the app, then try each one: the phone in airplane mode, the PIN at the keypad. If anything still opens, revocation is not yet effective. Keep testing until rejection to measure the delay; one successful opening establishes only a minimum delay.

How long should a phone permission stay valid?

Split credentials by who holds them, because the right validity is different for each.

Tenant PINs and cards live in the lock, with validity matching the rent period plus whatever grace the owner chooses. Payment extends it. Move-out deletes it at the door.

The manager's phone permission is different. The app on that phone holds the authority to create and delete keys at any door, even with no signal. That permission should last days, not months. When the phone is online, which in an Indonesian city is nearly always, it renews quietly in the background.

Short validity exists for the lost-phone case. If the manager's phone is lost or stolen, the owner disables the account on the server immediately, which stops renewal. But the permission already cached on the phone keeps working offline until it expires. Its validity is the longest window in which a stolen phone can still hand out keys.

Master Lock settled on seven days for most of its products. For a kos, where the manager's phone connects every day, 24 to 72 hours is a reasonable setting. Add a screen lock or fingerprint on the app itself, so a found phone isn't an open one.

The nine-month figure above has an instructive origin. Per the WOOT paper, it was a workaround for a firmware bug that made the lock's clock jump forward: short passes would have expired early and locked legitimate users out. Which brings up the clock.

Why is the lock's clock a security setting?

Every expiry in the building, from the rent period to the cleaner's one-day PIN to the manager's 72-hour permission, is a comparison between a date and the lock's internal clock (a small battery-backed timekeeper, like a wristwatch inside the lock). Wrong clock, wrong answers.

The same paper shows how this gets abused. The command that sets the lock's time was meant for admins only. The app hid it from guests, but the lock accepted it from anyone holding a valid profile. A guest could roll the clock back to stretch their own access, or push it forward so every valid key looked expired and everyone was locked out.

For a kos, four rules cover it:

• Only the owner role can set the lock's time, and the lock itself enforces that, not the app.
• Time updates from the server are signed, so the phone relaying them can't change them on the way.
• The manager app shows the lock's clock at every visit and flags drift beyond a few minutes.
• After a battery change, check the time before walking away.

Clock drift in field devices is a wider problem than locks; the patterns are in when timestamps stop being evidence.

Who can hand out keys when the owner lives elsewhere?

Most kos owners don't live on the property. A caretaker (penjaga kos) does the daily work: showing rooms, handing over access, dealing with a tenant locked out at 11 pm. That calls for two roles:

• Owner: full control, including settings, roles and the clock.
• Caretaker: create and delete tenant keys at the door. Nothing else.

"Nothing else" has to be enforced by the server and the lock, not by hiding buttons in the app. The WOOT finding is the same lesson from the other side: the app hid the time button, but the permission underneath still allowed it. If a caretaker's permission technically carries settings rights, anyone who takes the app apart can use them.

A caretaker leaving is the highest-risk revocation in the building, because their phone can issue keys to every room. On their last day:

1. Disable their account the same day, so renewal stops.
2. If access must stop immediately, update revocation at every lock through a supported mechanism. If the system relies only on expiry, document that cached permission remains usable until it expires.
3. List every temporary PIN they created (cleaners, repair crews, relatives of tenants) and delete the ones still live.
4. Collect any mechanical override keys they held.

What does the lock record, and can the record be trusted?

Two different logs get confused here.

The grant log records who got access to which room, which manager created it, and when. The server should record it when the action is confirmed. For offline manager actions, distinguish device timestamps from later upload times and verify that all grants reach the server.

The door log records when a door actually opened, and with which credential. In a Bluetooth-only lock, those events wait inside the lock until a manager's phone connects and uploads them. The phone is a courier, and couriers can lose parcels. The WOOT researchers showed they could plant fake entries in the log and keep genuine ones from being uploaded.

So be precise with the owner about which question the system answers. The grant log answers "who did I give access to?" A Bluetooth-only door log answers "roughly who opened, as far as the phones delivered," which is weaker than evidence for a theft complaint. If door logs need to hold up in a dispute, signed lock events and regular uploads can strengthen the record, but completeness, time accuracy, and secure key management also need testing.

Entry times are also personal data under Indonesia's personal data protection law (UU PDP). Decide up front how long they're kept.

Do phone-wallet keys change any of this?

The Connectivity Standards Alliance, the group behind the Matter smart-home standard, published Aliro 1.0 on 26 February 2026: a shared standard for carrying door keys in the Apple, Google and Samsung wallets, over NFC tap, Bluetooth, or Ultra-Wideband (short-range radio that measures distance, for hands-free entry). The alliance lists more than 220 member companies and names places without network coverage among its targets.

For a kos, that could eventually mean a tenant opens their room from the phone wallet with no app to install. It doesn't retire the four questions above. A wallet key is still a pass carried on the phone, and the announcement doesn't describe how a deletion reaches an offline door. Ask each vendor directly. For locks bought in 2026, PIN and card remain the practical default. Wallet support is a roadmap question, not a reason to buy.

What to ask before buying locks for a kos

1. When I delete a tenant, what changes inside the lock, and when? Show me.
2. How long does a manager phone's permission last offline, and can I set it?
3. Who can set the lock's clock, and does the lock itself enforce that?
4. Can the caretaker role be limited to issuing and deleting keys, enforced on the server?
5. Where do door-open events come from, and can a phone alter or drop them?
6. Has a security advisory been published for this lock's firmware, and was it fixed?

A lock in a kos with no front desk is a receptionist that works alone, at night, on batteries. Ask it the questions you'd ask a receptionist before handing it every room.