Long-term readers of this blog know that I rarely focus on a single company or product. My goal is to help readers understand new and emerging technologies, when and why they might be useful, and what to consider if you are buying them.

But this week’s blog, and another one soon, will deviate from this format to look at new companies that are, to me, just too interesting to ignore. I am not compensated by these companies, and these are NOT recommendations to buy. Today’s company is early stage, deployed at a launch site but not proven at scale. I want to give you a deep dive because it provides a glimpse, however tentative and imperfect, into core technologies that I think will be an important part of the future in hotels and travel, with potential big benefits to the hotel, to guests, and to the objective of greater security, data privacy, and compliance.

Today’s blog is about PassiveBolt, a company that is spearheading the marriage of digital access control with self-sovereign identity (SSI). I have been watching it for six or eight months with the usual skepticism I apply to most early-stage efforts. But unlike most, PassiveBolt’s progress is playing out largely as it had predicted. It just went live with its first commercial hotel deployment, meaning that this marriage, long discussed in concept, has moved from the world of the theoretical to the practical. First deployments hardly represent proven, scalable technologies, but every successful innovative product starts with a launch site, so the good ones are worth watching.

If you’re not familiar with SSI, it’s time to change that. SSI is a key element of Web 3.0 and it’s coming like a freight train. Most of the supporting standards are now fully vetted and published by the Worldwide Web Consortium (W3C), the same organization that defines HTML and other standards that run much of the Internet. I published SSI primers in this blog about 18 months ago and this one from two years ago, and I have not been disappointed with the pace of progress since.

Last summer, SSI became an official part of Microsoft’s Azure suite (under the name Entra Verified ID) and it is rapidly evolving into national digital identity programs within the European Union. Just two weeks ago, the EU published the architecture and reference framework for its SSI identity wallet, a technology very similar to the one used by PassiveBolt and covered below. EU adoption of SSI is no surprise, since it natively implements the major principles of the EU General Data Protection Regulations (GDPR), giving individuals real and secure control over their personal data and vastly simplifying compliance (and lowering risk) for anyone, such as hotels, that use it.

SSI is not about access control, it’s about proving who you are in a secure, privacy-first manner. Access control just happens to be the first application where I have seen it applied commercially in hotels. Many more are in the works; watch this space.

Who Is PassiveBolt?

PassiveBolt is a young startup, but only in a technical sense. It was until about five years ago a unit of Continental Group, a 150+ year-old auto industry supplier and a public company with revenues of about $35 billion annually. The group that was spun off into PassiveBolt (with funding from Continental) was responsible for developing access control (capacitive touch and digital access) that has been deployed in 120 million automobiles worldwide, including ones made by Ford and Fiat Chrysler. Since Continental is focused on the automotive industry, the spinoff enabled its access control capabilities to be more easily leveraged into other industries, including hotels, residential, commercial, and educational settings.

Because of this PassiveBolt is in many ways more of an established company entering new markets, including hospitality, than a traditional startup. Its track record includes multiple patents granted and pending, and numerous industry awards including the Consumer Electronics Show (CES) Innovation Award in both 2021 and 2022.

The company has developed and now deployed a new hotel access control paradigm built on SSI. It is not yet a complete solution that can be deployed at scale for most hotels (that will need a bunch of integrations), but it’s enough to understand the technology and how it might fit into the hotel environment. The pieces SSI components are essentially complete and working. The parts yet to be built are comparatively straightforward tasks around integrations needed to fully deploy capabilities like mobile check-in.

Hotels are not the company’s only target. PassiveBolt is also working with a major rental car company on a pilot, as well as with a large car manufacturer for access control to its facilities. In both cases it can leverage longstanding relationships from its days as part of Continental. The company’s demo shows the integration of keys from multiple such issuers (including the first deployed hotel, a rental car, and an office building) into a single wallet on the phone of a user. It is not hard, given their history, to see digital car keys provided by auto manufacturers moving into the same wallet quite rapidly.

Some Background on Access Control Systems

Door lock technology in hotels has not changed very much in the last 20 years. The security of Near-Field Communication (NFC) card keys has been upgraded since the days of Mifare Classic cards, and the major door lock vendors started deploying mobile key using Bluetooth Low Energy (BLE) nearly a decade ago. Mobile key is certainly a convenience for guests in some situations, but usage has remained very low. In my view, that is mostly because of the multiple steps that users must go through every time they want to use it, and the need to set it up separately for each hotel or brand.

In 2021, Apple announced support for digital NFC keys, which can greatly simplify the user experience. However, these are still only deployed in a small number of hotels. Digital NFC keys were not really a big change to the door lock systems themselves, but rather to the keys. Most hotel locks already support NFC communication and don’t know or care whether how the credentials are presented.

Hotel access control systems are among the few that still use (for the most part) non-networked (offline) locks. Corporate, car rental, education, and residential access control systems have increasingly moved to online locks. These have many advantages, such as the ability to revoke access in real time, or to reassign a key from one room to another without physically re-encoding it (which for the guest means schlepping back to the front desk), or to monitor suspicious activity as it happens. However, online locks have historically been expensive for hotels: each lock needs an embedded radio capable of receiving or sending a reasonable-sized payload. From a practical standpoint, battery-powered locks could not really meet this need, and the cabling required for powered locks was cost-prohibitive for most hotels.

PassiveBolt’s solution can support fully online locks where available, but it can also achieve some of the benefits of online locks without most of the expense. It can do this by leveraging BLE infrastructure (either already present or easily added in most hotels) to be able to send data to the lock (notably a list of revoked keys). And where that is not possible or not needed, it can drop back to the traditional (but less secure) way of disabling keys, where a key either expires at a given time or the lock no longer honors it because a newer key has been presented.

How SSI Can Support a Better Lock Solution for Hotels

SSI makes it a simple matter to store multiple keys to different things in one place on your phone, including keys you own (such as for your front door or car) and ones you have time-limited permission to use (such as for a rental car, hotel room, dorm room, or office). It does for locks what Apple and Google wallets have done for credit cards, reducing or eliminating the need to carry physical credentials while providing the convenience of tap-and-go recognition and acceptance. If you have keys to several doors or vehicles on your phone, you just hold your phone near the lock, and the right key will be used to open it. Where higher security is needed, there are options such as requiring that your phone be on and that it pass a biometric check like Face ID, or that the key be presented from the app’s or phone’s native wallet.

Keys issued within the SSI framework are digital, cryptographically signed, and provable. One credential (stored permanently on the user’s phone in PassiveBolt’s model) identifies the person to whom access is to be granted and guarantees they are a real person (typically verified by government ID). Another states that that individual has the right to “unlock” a door, car ignition, or whatever. When the same person can present both credentials to a hotel lock (via NFC or BLE), then the lock can verify cryptographically that (a) the hotel, office, rental car company, university, or building issued the key to a specific person, (b) that the person should have access to the door that the lock controls and, if desired, (c) that it is in fact that person, and not someone else, presenting it (by requiring biometric proof like Face ID on the phone).

Most of the current generation of hotel locks cannot do (a) or (c) with either plastic or mobile keys; they only know that a valid key has been presented, not by whom. And as for (b), most hotel locks have no way to know if an issued key has been revoked, unless a newer valid key has been presented to the lock. PassiveBolt’s SSI-based solution appears to address these limitations.

Aside from making it easier for the guest to manage multiple digital keys controlled by different entities (rental car companies, hotels, universities, offices, etc.), the SSI design has some real-life benefits for hotels, beyond potentially greater security. New keys can be issued remotely, meaning that if a guest needs to change rooms, the hotel can re-issue the key without the guest having to trek back to the front desk. Similarly, if a guest should have access to a meeting room or to the executive lounge, but did not get the appropriate keys at check-in, an updated key can be sent directly from the hotel to their phone.

An SSI approach also provides options whereby a guest of a major brand could register once, and automatically, even behind the scenes, receive keys for every guest stay across every hotel in the brand (or at least those that support digital keys).  Once the guest has confirmed check-in and been advised of their room number, they could simply tap their phone on the guest-room door; no need to open it up or turn on an app. While technically a different key would be used than at any prior hotel, the replacement could happen behind the scenes, and work with any locking system that supports the SSI wallet. From the guest standpoint, they simply have a key that works at any hotel in the brand – and any other brand supporting the same wallet.

The PassiveBolt User Experience

Setup. For the user (hotel guest, car renter, etc.), the process starts with downloading PassiveBolt’s app (KeyShare, available for iOS and Android) that will hold, manage, and present their keys, as well as selected personal information. And whereas hotels have been challenged getting guests to download apps for a single purpose, KeyShare can give guests more reasons to download it. Adoption by even one auto manufacturer or major rental car company would create millions of travelers who already have the app and can therefore use it at any supporting hotel.

The first time they use the KeyShare app, the user must go through a one-time Know Your Customer (KYC) process. This enables PassiveBolt to provide the highest possible assurance that the mobile device is owned by a real person with verifiable identification. The process is similar to many hotel mobile check-in processes I have seen, except that it need only done once and can then be used for verifying the issuance of any future keys from any source.

The app takes a photo of a driver’s license or other identity document, validates its format, verifies its issuance, and compares live, real-time selfie to the photo on the identification. It also makes 58 background checks including things like the no-fly list and terrorist watch list. Once validated, the guest enters at least minimal profile information, contact details, and optional preferences. This is stored once, on the user’s phone and/or in a backup personal storage location, in a way that makes it simple for the guest to provide appropriate details to any hotel, car rental company, or other provider.

One end result of the process is a digital credential stored on the user’s phone that can be presented to a lock (or really to anyone) to prove who the user is. The credential is under the user’s control, but also cryptographically includes the proof that the user has gone through the KYC process. As with all SSI identity credentials, the cryptographic proofs are stored on a blockchain to ensure provenance and make them tamper-proof, while personal details are stored on the user’s mobile device or in a secure web storage location of their choosing.

The blockchain used by PassiveBolt is a special purpose one called NFID, which they designed themselves to support specific cryptographic requirements of the access control industry (for the technically inclined, most digital locks use Elliptic Curve Cryptography). While mappable to digital identities stored on other blockchains, NFID adds the cryptography layer that digital locks understand. The NFID blockchain is planned to be governed by a consortium open to companies operating in the access control space. Once this happens, it ensures that no one company can control it in a self-benefiting way.

The user can also link ancillary devices, such as a watch or tablet, to the identity stored on the mobile phone, allowing a door to be unlocked with any of the linked devices.

Adding Keys. Once they have the app and a proven identity, the user can now receive “keys” issued by any company that controls access to a building, car, or other space. These keys are created and stored according to the W3C Verifiable Credential standard, which essentially guarantees that the issuing party is one that is trusted by the access control system. The keys are specific to each user and can only be used in tandem with the credential that proves the user’s identity.

There are benefits of handling the user’s personal data, KYC proof, and keys in this way. First, the user controls their personal data, sharing it with hotels, rental car companies, or others only to the extent they like. Of course, travel suppliers will continue to require certain basic information as a condition of doing business with them, but the user must explicitly approve the sharing of information as part of the reservation or check-in process. The user can also set an expiration date for access (although the hotel may set a minimum).

Hotel policies can be as strict or as lax as they like, and might vary depending on their view of the risk level of a particular guest. For example, a hotel might want to require biometric verification (e.g., Face ID or fingerprint) at check-in only, or every time a digital key is presented to a lock, or not at all. In concept, this could even vary by individual, perhaps with looser requirements for regular, repeat guests.

Check-in. For check-in, the hotel can “push” a message to the guest app using a private peer-to-peer channel that supports the emerging DIDComm protocol, another emerging SSI component. The user must first accept the request to open the channel. After that, the channel remains open for future use unless either the hotel or user chooses to close it. Once the user accepts, the hotel can send a check-in “button” via the channel. The user can click the button to check in using all the relevant information already stored in their profile or can choose which specific information they are willing to share. For its part, the hotel can specify the minimum information that must be shared to complete the check-in; it can also require a signature indicating acceptance of the hotel’s terms and conditions if desired. The information is sent back to the hotel via the DIDComm channel, and the hotel checks the guest in.

Mobile Key. Once the guest has been checked in, the hotel system returns a key via the DIDComm channel. In the pilot, this is a manual process handled from a console at the hotel, but a PMS interface would automate this process in the future. If the guest has a problem with the room, they can also message the hotel via the DIDComm channel, for example to request a different room; in this case the hotel can assign a new room and deliver the new key directly to the guest’s phone “over the air.”

‍How PassiveBolt Works with Door Locks

The solution is designed to work with any existing door locks. It does require an upgrade that each access control vendor will need to support (for most this is a simple software upgrade). The company deployed first with PDQ, a manufacturer of physical lock hardware, and uses a PassiveBolt control unit. PassiveBolt is currently in discussions with a major hospitality lock company to implement their software in existing locks. They expect other lock vendors will come on board over time (and based on what I know I think this is likely), but this is of course not guaranteed. For now, the important takeaway is that the design allows most existing hotel door lock hardware to be upgraded rather than replaced.

Credentials are presented by either NFC or BLE (or can use any other communications method), with specifics determined both by choices made by the hotel and the guest. For example, NFC can be used without opening the phone, but either the hotel or the guest might specify that Face ID authentication is required, in which case they will have to open the phone and either the app or their Apple or Google wallet. The locks can verify that a presented key is valid for the room, has not expired, is not on a revocation list, was issued to the person who owns the device, and (with biometric identification) that the same person is presenting it.

If the hotel wants to revoke a key, a message is sent to the phone and to the lock (typically via a broadcast BLE message) that the key has been revoked. Once either message has been received, the key will no longer open the door. Delivering the required information to the lock requires at most a minor infrastructure upgrade in any hotel that offers guest-room Wi-Fi. Most Wi-Fi access points now include BLE transmitters, but if they do not, BLE hubs can be added. If for any reason the lock cannot receive broadcast messages at all, then it can fall back to the traditional key rotation approach to deactivating revoked keys (where the lock stops recognizing a key when the next one in sequence is presented).

The Hotel Experience

The hotel where PassiveBolt has been installed is quite basic and much of the pilot process is manual. It is enough to prove out the concept and identify issues, but additional automation will be needed to meet the needs of most hotels.

Like the user, the hotel itself has its own digital ID (DID, in W3C terminology) that definitively and securely identifies it. The hotel also has a wallet, which it would typically access from a desktop computer or other device. That wallet is basically the user interface where the hotel (or its systems) can send messages (again using the DIDComm protocol) to guests who have wallets on their phones.

Typically, the hotel would send a form email or text message from their reservation system, PMS, customer relationship management system, or chat platform inviting the guest to take advantage of mobile check-in and mobile key and instructing them how to set it up. Once set up, the hotel wallet can send a DIDComm message to open a channel to the guest’s wallet, which the guest must accept.

When mobile check-in becomes available for the guest’s stay (e.g., 24-48 hours before arrival), the hotel can send a message via DIDComm with action buttons for the guest to check in. When the guest pushes the check-in button, the hotel gets whatever information the user has authorized sharing, assigns a room, waits until the room is ready (if needed) and then uses its wallet to issue a key and send it to the guest. In the first installed hotel, these steps are initiated manually, but with an interface, the DIDComm channel would be connected to the PMS and the hotel’s wallet to complete the transaction automatically.

The DIDComm channel can also be used to communicate with the guest via text about issues related to check-in, but also for marketing or other purposes. Messages support metadata and action buttons. At a large resort, for example, it might push directions or even a map showing them how to get to their room.

The solution is an alternative to, but does not displace, the role of hotel apps that support mobile keys. PassiveBolt intends to offer a Software Developer Kit that will enable those apps to incorporate its capabilities behind the scenes.

Business Model

It’s always risky to talk about the business model and costs of a product that’s a totally new concept and that hasn’t yet been market tested. PassiveBolt currently plans to offer its product as a service at a monthly fee per occupied room. Its research suggests that the cost will be competitive with other options, but because many current solutions are sold largely on a capex basis, that calculation may not consider the sunk capex costs of recently installed systems. Long term, the concept looks promising, but there are likely to be some kinks to work out, and the economics may not make sense for every hotel right away.

The Caveats

This is a first deployment of a proof of concept that uses a totally different set of technologies that support greater privacy, security, and convenience for hotel door locks. Anyone seriously interested in access control, security, or data privacy should look at it and monitor developments, and maybe even consider piloting it at some point in time.

For the solution to be viable in more than a few independent hotels, several points of resistance need to be addressed. There are still a lot of unknowns as to how to achieve that.

• The major hotel locking systems need to sign on. I know of a few good reasons why they might want to do this, but there is no guarantee they will, or how long it will take. The software upgrades to existing locks are simple, but interfaces with the control software are also needed. No major brand will be able to deploy this at scale until all the vendors their hotels use support it.

‍

• The NFID blockchain that issues identities must move from its current PassiveBolt ownership into a neutral environment controlled by entities that hotels, car manufacturers, rental car companies, and others trust. This is PassiveBolt’s expressed plan, but at least a few other credible companies need to step up in order to make it happen.

‍

• A company (probably not a hotel) with a lot of locks used by travelers, and that can control them all centrally, needs to prime the pump of users. One or a few of the major rental car companies are the obvious candidates; they already use the technology, and their fleets support it, so in most cases they can roll it out fleetwide in a single project. This greatly reduces the barriers for a guest using it in a hotel, especially since most brands cannot support mobile keys at every property.

‍

• Integrations with PMSs, payment gateways, hotel chat software, and other systems are needed to fully automate the check-in process and messaging capabilities.

‍

• Consumer resistance to digital keys needs to drop. Very few hotels that support mobile keys get more than single-digit percentages of guests using them today. This will change as digital keys become more common in other settings and as lower-friction NFC keys become more common. But it will take time – perhaps several years – to become mainstream. Few guests will download PassiveBolt’s app just to get a digital key for a single hotel. That’s especially true because of the KYC process, which takes a couple of minutes and makes sense mostly if you expect to be able to use it to get keys to multiple doors, cars, or other places – or anything you would use every day, such as your own house or car.

‍

• Numerous edge cases need to be addressed. For example, a primary guest may need to authorize an additional key for traveling companions.

‍

• The PassiveBolt wallet and KeyShare app capabilities need to be integrated into brand apps, potentially using the company’s planned software development kit. It’s unlikely the brands will deploy mobile keys that require a separate app.

‍

• Hotel owners need to be convinced of the economics. What I have seen suggests that the longer-term costs may be competitive with existing solutions, but this will not be the case for every hotel, and even where it is, many owners have short-term horizons that don’t align with longer term ROI calculations. This may complicate adoption by major franchise brands.

These and other barriers suggest that adoption of a technology like this in hotels will not happen overnight. The reason I think it is likely to happen eventually is that I think this technology – whether from PassiveBolt or others – will take hold soon in other industries and will start to set consumer expectations in ways that hotels will be unable to ignore.

‍