The guest had a card. The hotel had a master key. Cody Brocious had a small homemade device that cost less than $50. In the summer of 2012, that was enough to open a hotel-room door without either of the first two. [1]

Not every door, and not reliably at first. When Forbes reporter Andy Greenberg accompanied him to three New York hotels, the prototype opened one of three tested locks, after adjustment. That was a poor batting average and a perfectly good reason to worry. [1]

VingCard had helped make hotel access changeable between guests. Onity’s story exposed the other side of programmable access: the machine needed instructions, and someone had to decide whose instructions it should believe.

The other way in.

Brocious presented his findings at Black Hat’s Day Zero event in Las Vegas on 24 July 2012. His subject was the Onity HT hotel-lock system: familiar electronic locks with magnetic-stripe guest cards, not an internet-connected smart-home gadget. [2][3]

Alongside the card reader was a service interface. Hotel staff used a portable programmer to set up locks, update their settings, read opening records and open doors. Those were useful powers. They also made this a second access path worth protecting. [3]

The fault was that the interface allowed memory to be read without authentication. A secret used to authorise opening was held in that memory. An outside device could obtain it and impersonate the programmer’s privileged request. The guest-card check never entered the conversation. [3]

Inside the failure

Two paths. One door.

  1. 1 / 4

    The entrance everyone sees.

    A guest presents a credential. The lock checks it before releasing the door.

    Guest path

    1. Guest card
    2. Credential check
    3. Authorised opening

    Service path

    1. Hotel programmer
    2. Service interface
    3. Maintenance functions

    Permission is checked on the guest path.

  2. 2 / 4

    The entrance staff need.

    The programmer also has a legitimate route to settings, records and opening functions.

    Guest path

    1. Guest card
    2. Credential check
    3. Authorised opening

    Service path

    1. Hotel programmer
    2. Service interface
    3. Privileged functions

    Maintenance carries powerful permissions too.

  3. 3 / 4

    The boundary fails.

    An untrusted device could read protected information without proving it was authorised.

    Guest path

    1. No guest card
    2. Card reader unused
    3. No guest permission

    Service path

    1. External device
    2. Unauthenticated read
    3. Secret disclosed

    The lock exposed the secret it relied on.

  4. 4 / 4

    A request mistaken for authority.

    The device used that information to have an opening request accepted through the service path.

    Guest path

    1. No guest card
    2. Card reader unused
    3. No guest permission

    Service path

    1. External device
    2. Privileged request accepted
    3. Door opens

    Unauthorised opening. The same flaw repeated across affected locks.

A simplified trust diagram, not a circuit or protocol. Arrows show the logical sequence, not wiring or the direction of every data exchange. The attack required physical access to an affected lock; it was not a remote command to every room. [3][1]

This was not one universal password for every hotel. It was a repeatable way to cross the same broken boundary. The modest price described the demonstration hardware, not a retail master key guaranteed to open any room. [1][3]

A bug with millions of addresses.

Contemporary Forbes reporting put Onity’s installed base at four to five million hotel-room locks, citing the company. Brocious’s slides said over four million HT locks. Black Hat’s event description used nearly ten million. These were estimates of reach, not a count of doors successfully tested. Millions is the defensible scale; a precise global total is not. [1][3][2]

That distinction matters. A flaw in a single lock is a repair job. The same flaw across a widely deployed product becomes a coordination problem: identify the hardware, reach the owners, agree on a remedy and get someone to every affected door.

Public disclosure added urgency and risk. Brocious released his work, and others refined it. He had not privately notified Onity before the talk; Greenberg had contacted the company for his reporting. Guests and hotels needed to know. So did the people who would use that knowledge badly. [1][6]

A plug is not a patch.

Onity initially described the method as unreliable and complex to implement. Its 13 August statement proposed two responses: free physical caps and security screws to obstruct the HT service port, and upgraded firmware for HT and ADVANCE locks. For HT, that second route involved replacing the control board. [4]

The distinction was important. A cap limited access to the vulnerable interface. Updated electronics addressed the system behind it. Both required action at the property; neither arrived simply because a press release had been published.

The August plan left shipping, handling and installation labour with hotel owners, with possible board fees and special pricing for older locks. A cheap demonstration had produced a decidedly uncheap maintenance exercise. [4]

By December, Greenberg had obtained memos describing reimbursement arrangements for Marriott, IHG and Hyatt properties. The terms differed by chain and equipment; this was not a universal free replacement programme. Onity’s public response said it had shipped 1.4 million remedies by 30 November and would send the mechanical solution to properties in its database. Shipment was not proof of installation. [5]

Then the rooms were empty.

In November 2012, Forbes reported September thefts at a Houston Hyatt. Its operator, White Lodging, believed the Onity weakness had been used. The police spokesperson did not confirm the entry method. The operator said it had learned of the vulnerability in August and blocked the ports after the thefts. That is a reported connection, not forensic proof of every break-in. [6]

By May 2013, police were describing suspected use across several Arizona cities. In one Phoenix case, police said the lock’s records showed device access during the suspects’ visit, although the surveillance footage did not show the door being opened. The evidence had moved beyond an alarming conference demonstration. [7]

WIRED’s 2017 follow-up traced Aaron Cashatt’s burglary spree through interviews and police material. Greenberg also retested four hotel rooms: three resisted his device; one still opened. That tiny sample could not measure the remaining exposure. It did show that years after disclosure, the repair story was not uniformly finished. [8]

The key is only one part of the lock.

The lesson is not that a metal key would have solved everything, or that today’s Onity products share this historical flaw. It is that the guest-facing credential tells only part of the security story. A beautiful mobile key cannot, by itself, tell you whether the maintenance route is well protected.

Modern guidance makes the wider obligation explicit. NIST’s device-security baseline calls for restricting local and network interfaces to authorised users or devices, protecting stored data and providing secure software updates. Those principles apply beyond hotel locks. They are also a useful way to read this particular failure. [9]

For a hotel choosing access equipment, the useful questions extend past what the guest taps. Who can issue a privileged instruction? What can the service interface reveal? How will a flaw be fixed, who will pay, and how will the hotel know that every affected lock has been dealt with?

Programmable access lets a hotel change its mind about a key. It also means the lock has more than one conversation worth securing.

In 2012, the expensive lesson arrived in a cheap device. The door did not need a better guest key. It needed to be more careful about whom it believed.

Series

Companies That Shaped Keyless Check-In

The companies, products and decisions that changed how keyless access looks, works and gets sold.

  1. Part 1VingCard: the hotel key learned to forget
  2. Part 2What happened to Latch? Beautiful locks, broken numbers, and the new DOOR
  3. Part 3Onity: the $50 hotel master keyYou are reading
  4. Part 4SPG Keyless: the future still needed a keycard
  5. Part 5How Airbnb shaped self check-in — and the dependency behind the door

Based on the original conference slides, Onity’s reproduced statements, contemporary reporting and later follow-up. Historical estimates and reported crime links are attributed. The visual explains a trust failure, not an operational attack. Pull quotes are editorial observations. This is not an assessment of current Onity products. Facts checked through .

The paper trail

Sources & notes

9 sources
  1. Andy Greenberg, Forbes — original Onity investigation, 23 July 2012

    First-hand demonstration and three-hotel test: one success after adjustment. Reports less than $50 in hardware and a company-sourced installed-base estimate of four to five million rooms. The page was later updated; subsequent developments are sourced separately below.

  2. Black Hat USA 2012 — Day Zero event programme

    Schedules Cody Brocious’s talk for 24 July, before the main 25–26 July briefings. Its nearly-ten-million estimate differs from the slides and contemporaneous reporting; it is not used as a verified affected-lock count.

  3. Cody Brocious — original Black Hat presentation slides

    Primary technical account of the HT system, portable programmer, unauthenticated memory access and opening authority. The site code identifies a property, not a universal master password. The slides say an opening can appear in the audit as programmer use; the article therefore avoids calling the attack traceless. Operational instructions and separate card-cryptography attacks are outside this feature’s scope.

  4. Onity’s 13 August 2012 statement, reproduced by SecurityInfoWatch

    Published 24 August. Preserves the manufacturer’s proposed mechanical caps, screws and firmware programme, including HT board replacement and cost allocation. ADVANCE appears in the response; the original demonstration and this feature focus on HT. Proposed availability is not evidence of completed installation.

  5. Forbes — replacement-board reimbursement arrangements, 6 December 2012

    Reports different arrangements for Marriott, IHG and Hyatt and reproduces a Marriott memo. Onity did not confirm the private agreements to the reporter. Its quoted public statement reported 1.4 million solutions shipped by 30 November; this is not an installed or independently verified repair count.

  6. Forbes — reported Houston hotel-room thefts, 26 November 2012

    White Lodging attributed September incidents to the vulnerability. The Houston police spokesperson did not specify the entry technique. Arrests and allegations in contemporary reporting are not presented here as convictions or proof of each incident.

  7. Forbes — Arizona police reports and continuing burglaries, 15 May 2013

    Reports police suspicions across Phoenix, Scottsdale, Tempe and Mesa, including lock-audit evidence described by police in one Phoenix case. It does not establish a complete national crime count.

  8. Andy Greenberg, WIRED — five-year follow-up, August 2017

    Retrospective reporting on Aaron Cashatt and a four-room test that found one remaining vulnerable lock. Neither that sample nor the burglar’s success claims establishes prevalence in 2017 or the state of current products.

  9. NIST IR 8259A — IoT Device Cybersecurity Capability Core Baseline

    May 2020. Data protection, logical access to interfaces and secure software updates inform the closing analysis. This later general baseline is not a hotel-lock certification or a rule claimed to have applied to Onity in 2012.