News
SECRA data breach: holiday accommodation access codes may also be affected
Access codes may be affected by the SECRA data breach. What is confirmed and how operators can check resets, property assignments and guest communication.
The SECRA Bookings data breach also raises a question about access to holiday accommodation: the company FAQ dated 30 October identifies potentially affected key-safe and safe combinations. Partners are being instructed to reset electronic lock PINs and key-safe combinations for affected properties.
A digital incident can therefore require action at a specific building. Operators need to establish which property needs a new code, who will change it and how guests who are already travelling will get in afterwards. The original statements do not confirm that unauthorised physical entry has occurred.
What is known so far
SECRA dates the discovery of the attack to 23 October 2026. Parent company HomeToGo published an ad-hoc disclosure on 24 October. It described the incident at the channel-management software provider and said that, at that time, there was no evidence of data exfiltration from other group companies.
The current FAQ confirms that data was exported. SECRA says forensic work is still establishing which individuals are affected. The company reports no indication of data misuse so far. Those interim findings establish neither that every property is affected nor that every individual access code is safe.
The news context for this article is the current FAQ dated 30 October, rather than the discovery of a new attack that day.
When a stored value can become a means of entry
An email address, a booking confirmation and a door code call for different responses. An access credential may remain directly usable while it is valid. Removing it from a booking system would not automatically invalidate a copy taken earlier.
Responding therefore depends on two relationships: Which code belongs to which property? And who needs to be informed after it changes? Without the first mapping, replacement remains incomplete. Without the second, authorised guests could find themselves unable to enter.
The broad finding that “data is affected” is insufficient for this work. Closing an IT ticket does not establish that a key safe at the property has actually been reconfigured.
What an operator should be able to trace
The following mapping is our editorial working aid for handling this type of incident. It does not describe publicly confirmed procedures at SECRA or individual hosts.
| Question | Useful working record |
|---|---|
| Which property and access point are involved? | An unambiguous property identifier and the type of access, such as an entrance lock or key safe |
| Which credential is being replaced? | A reference to the affected code version; the actual code does not belong in a widely visible task list |
| Who can make the change? | A named responsible person, an available deputy and, where necessary, access to the property |
| How will completion be established? | Confirmation of the change and a suitable functional check using the relevant system procedure |
| Who needs the replacement access? | A mapping to upcoming and ongoing stays, as well as authorised service personnel |
| Which exception remains open? | A recorded issue to resolve, an assigned person and the next specific action |
Properties do not all use the same locking system. A management company should distinguish between changes that can be made remotely and those requiring someone to operate the device on site. Unclear ownership is more than an administrative concern: it can stop a necessary change from happening at all.
A changed code must also work in practice
A realistic process finishes by checking the outcome. For an electronic lock, this might mean checking the intended new access using the manufacturer's procedure and checking the validity of the replaced credential. A mechanical key safe requires an appropriate check at the device. The safe and available method depends on the particular system.
Ongoing stays also need to be considered. A change without an agreed handover could lock out authorised people. Such cases require an available contact and a suitable fallback arrangement; a generic “PIN updated” message does not complete the operational work.
Exceptions belong in the incident record too: Who has been unable to reach an owner? Which property has not provided an update? Where has confirmation arrived without a clear property reference? These questions can be worked through individually instead of closing the entire incident prematurely.
What guests should clarify
Travellers should confirm access with the official contact in their own booking documents. An unexpected last-minute change should not be handled through an unverified link in a message.
Clear communication distinguishes between a change to property access and a request for an additional payment. One does not automatically imply the other. When in doubt, a call using an already known contact channel is sensible. Replacement codes should reach only authorised recipients through the intended channel.
An incident report or shared task list should not become a collection of valid door codes. The property identifier, an appropriate reference and evidence of the action are enough for the working record. Access to the actual credential requires a suitably restricted group.
What the publication does not establish
The publicly available information does not provide a completed mapping of all stolen records to individual properties. Potential exposure of a code is not proof of a break-in. Equally, an outstanding mapping is not a useful reason to postpone necessary enquiries about one's own property.
A provider's notification also does not replace checking one's own situation: Which data was processed for the relevant bookings? Which access credentials were stored in it? Which confirmations have already been received? New company updates may change that picture; their dates and statements should remain part of the incident record.
Keeping the response together
The case illustrates a specific benefit of clearly assigned information assets: a data category needs to be connected to the affected property, a responsible role and a verifiable action.
Kopexa supports a structured response through assets, risks, tasks and evidence. A code-replacement task can consequently have an assigned owner and a record of the work. The actual reset and the check at the lock or safe are performed by the responsible operators using their respective systems.
For an initial situation report, the incident report template helps separate facts, impact and outstanding work. In this type of case, “information sent” is not the complete outcome: the correct property needs to have been addressed while authorised access remains organised.
Cover: AI-generated illustrative photograph of holiday accommodation with a key safe; not an affected property or a photograph of the incident. Design: Kopexa. Editorial position and sources checked: 30 October 2026.