Changing the code “regularly” doesn’t fix this, because the problem isn’t the schedule, it’s that one code gets shared by everyone who’s ever stayed. The actual fix is a code that belongs to a single booking and expires automatically at checkout, so there’s nothing left behind for a past guest, or anyone they passed it to, to come back and use.
Why doesn’t changing the code “regularly” actually fix this?
Because between changes, the old code still works for everyone who has it. A key safe or a fixed keypad code is a static secret. Every guest who has stayed gets the same digits, and every one of them keeps those digits after they leave, whether or not they meant anything by it.
Airbnb’s own safety guidance recognises this is a live risk, which is why it tells hosts: “Keys or access codes should be provided for the main point of entry. Lockboxes and entry codes must remain secure, and hosts should change codes between each reservation.” That’s a sound instruction. It’s also a chore that depends on someone remembering to do it, every single changeover, for as long as the property is let.
And the risk isn’t limited to the guest who stayed. LockGuy, a UK locksmith writing about short-term lets, puts it plainly: “That guest that stayed in an STR property and was given the key safe code legitimately could pass it on to any number of people.” A code that’s been handed out once has no way of knowing who’s holding it now.
What does a code that expires at checkout actually stop?
It stops the one specific thing that makes a shared code risky: the code outliving the booking it was meant for. A code generated for one reservation and switched off the moment that reservation ends can’t be used by the guest who stayed last month, because it no longer exists. Nobody has to remember to change anything, because there is no shared code left behind to change.
| What happens | One shared code (key safe or fixed keypad code) | A code per booking |
|---|---|---|
| Who can get in | Anyone who’s ever had the code, or anyone they gave it to | Only the current guest |
| When it stops working | Only when someone remembers to change it | Automatically, at checkout |
| Risk window | Open-ended | One booking, then closed |
This pattern isn’t unique to any one company. Airbnb’s own native smart lock integration works this way: “The default setting is for guests’ codes to expire 30 minutes after checkout. You can adjust this so that guests’ codes stay active from 15 minutes to 2 hours past your listing’s checkout time.” Codes are also issued automatically per reservation rather than typed in by the host each time, which is what makes the expiry reliable instead of something someone has to remember to set up for every booking.
What expiry does not stop is anything that happens during the live booking. If a code is shared while the booking is still active, it will work, because it’s meant to. Expiry closes the gap after a guest leaves. It isn’t a claim that the system can’t be misused while someone is legitimately staying, and it’s worth being honest about that distinction.
What about the code pasted into a WhatsApp group?
This is the hole that per-booking expiry doesn’t close by itself, and it’s worth naming directly. A guest who forwards the door code to three friends joining them for the weekend has done nothing against your house rules, and nothing the code itself prevents. A forwarded code is just as live as the original. A guest sharing it innocently makes no difference, because the code stays valid either way.
What closes this isn’t a cleverer code, it’s the booking terms. The guest agreement should say who the code is for and that sharing it outside the booking isn’t permitted, and the code should expire the moment that guest’s stay ends regardless of who else has seen it. That second part is what per-booking expiry actually buys you: it doesn’t stop mid-stay sharing, but it guarantees the sharing has a hard deadline, rather than going on indefinitely after checkout the way a key safe code does.
What happens when a guest extends their stay?
A code tied to a booking expires at that booking’s original checkout time. If the guest extends and the booking itself isn’t updated, the code can die while they’re still in the property, which is its own kind of problem. The fix has to be that extending the booking also moves the code’s expiry.
Airbnb’s own native lock integration handles this by linking the code to the reservation’s actual dates: “You can change the check-in and checkout times for individual reservations so that your guests’ codes are active during their entire stay.” That’s Airbnb’s own system, shown here as an example of how the pattern works generally, not a description of how AirPilot is built.
At AirPilot, the code is tied to the booking’s checkout time rather than a date someone typed in once. If the booking is extended and the checkout time changes, the code’s active window moves with it, because AirPilot connects to Airbnb, Booking.com and Vrbo through direct platform API connections rather than a pasted iCal link.
Why the connection method matters is a timing question, and it’s worth being specific about what’s industry context and what isn’t. Guesty, a property management platform, describes the general difference between the two methods: “iCal sync is slow. Updates aren’t instantaneous; they happen on a delay, often every hour or longer.” The same source describes API sync propagating a change immediately: “When a booking comes in on Airbnb, the API instantly tells Vrbo, Booking.com, and your direct site that those dates are occupied.” That’s general industry context on how fast a sync method reflects a changed booking across channels, not a measurement of how quickly any particular lock system picks up an extension. The underlying point still holds: a system reading live booking data has a better chance of catching an extension in time than one relying on a periodic calendar refresh.
What about the cleaner using the guest’s code?
This is an operational gap rather than a technology one, and it’s a common one. A cleaner who’s been given a guest’s code for convenience, because it was quick, or because nobody set them up properly, is now holding a code meant for someone else, on a schedule nobody’s tracking.
The fix is to give cleaners and contractors their own access, separate from any guest code, generated for the day or the job and switched off afterwards. In our experience this is the gap that actually gets exploited, not because cleaners are untrustworthy, but because a guest code that’s been shared once for a legitimate reason tends to just keep getting reused, long after the reason for sharing it has gone.
What does any of this cost to put right?
If you’re pricing a smart lock yourself rather than going through a managed service, Kingdom Locksmith gives a UK range: installation typically costs “between £190 and £320 for standard residential doors“, rising for uPVC or composite doors. If you’d otherwise be paying a locksmith to physically rekey a lock between guests, the same source puts call-out labour at “£75 to £125 per hour, plus a £65 to £130 call-out fee“, which is the real cost of trying to solve this problem manually, door by door, changeover by changeover.
AirPilot’s own prices for installing and managing a lock, or for self-install software only, are at /pricing.
In short. A single shared code is the risk, not the gap between changing it. A code that belongs to one booking and expires at checkout closes that specific hole. It doesn't stop a guest forwarding the code mid-stay, or a cleaner holding the wrong credential, so those still need handling through house rules and separate staff access.
Where AirPilot fits
If you’d rather not run this yourself across several properties, AirPilot surveys, fits and manages the lock for you. At AirPilot, every guest gets their own code, generated for that specific booking, and it expires when they check out. The lock stores codes on the device itself, so it keeps working if the internet drops, and every install keeps a mechanical key override. Support, including a lockout at 3am, is answered any hour.
Read more at /solutions/smart-access, see current pricing at /pricing, or book a demo to see it working. There’s also a free guide if you’d rather read first.