Aliro Digital Key Standard Explained: CSA Smart Lock Protocol

For years, tapping a phone to unlock a door has worked only if the lock maker, the phone maker and the wallet vendor had signed a private deal. Apple Home Key worked with Apple phones and a short list of locks. Everything else lived in a vendor app that you opened, waited for, and cursed at. The Aliro digital key standard, released by the Connectivity Standards Alliance (CSA) as version 1.0 in February 2026, is the first serious attempt to replace those private deals with one public protocol.

It matters now because certification has opened and the first wave of locks, readers and chipsets is shipping or promised. Whether a lock you buy in 2027 opens for a guest with a different phone brand depends on the decisions the specification makes about transports, cryptography and offline operation.

You will leave with a precise mental model of how Aliro is layered, how a tap or a hands-free approach becomes an unlock, what the credential and its policy look like, where Matter fits, and what can still go wrong.

What this covers: the problem Aliro solves, the reference architecture, the NFC, Bluetooth LE and UWB transports, the expedited and step-up transaction flow, credentials and offline policy, certification, a comparison with proprietary alternatives, failure modes, and a practical checklist for product teams and integrators.

Context and Background

Access control has always been a fragmented market. Corporate buildings run proprietary card systems on 13.56 MHz contactless cards. Hotels run their own encoders. Homes run a patchwork of keypads, Bluetooth apps and cloud accounts. When smartphones entered the picture, each ecosystem built its own bridge: wallet passes with vendor-specific readers, and per-brand apps that talk Bluetooth Low Energy (BLE) to one family of locks.

The consequences are familiar to anyone who has installed a smart lock. A lock works well with its own app and poorly with anything else. A property manager who wants to issue keys to tenants, cleaners and contractors must pick one vendor and stay there. A guest with the “wrong” phone cannot be given a key at all. The cost lands on manufacturers as well, because each wallet integration is a separate engineering and legal project.

Aliro is the CSA’s answer. The CSA is the same body that governs Matter, the smart home interoperability standard. According to the alliance’s announcement of 26 February 2026, Aliro 1.0 defines a communication protocol and a credential standard so that digital keys held in the native wallets on phones and wearables work with any compliant reader. The press release names Apple, ASSA ABLOY, Google, Infineon, Last Lock, Samsung and STMicroelectronics as member companies that pooled technology for the specification, and it states that the alliance has more than 220 members.

If you have followed our coverage of Matter 1.6.1 groupcast, NFC commissioning and Joint Fabric, you already know the CSA’s style: a layered specification, a certification program, and a long tail of silicon vendors implementing it. Aliro follows the same playbook but targets a different problem. Matter connects a device to a home network and an ecosystem. Aliro authenticates a person’s credential to a reader, often with no network at all. We return to the relationship between them later, because it is the most commonly misunderstood part of the story.

What the specification actually contains

According to coverage of the release, the specification runs to roughly 195 pages and is free to download after registering an email address. Its table of contents covers the architecture, a trust framework, the access document, the access protocol, and separate transport protocols for NFC, BLE and ultra-wideband (UWB). That structure tells you a lot. The protocol layer is deliberately separate from the transports, which is why the same credential can be presented by tapping, by approaching over Bluetooth, or by walking up with a phone in a pocket.

The CSA describes Aliro as a “living standard.” Secure key sharing, for example, is described as a planned later phase rather than part of 1.0, and the alliance says later versions are intended to remain backward compatible. Treat any claim that “Aliro supports sharing keys with a friend” as a statement about the roadmap, not about version 1.0.

Why the timing matters

Three things converged. First, phones and wearables now routinely contain NFC and, in many flagship models, UWB radios. Second, chipset vendors such as Nordic Semiconductor, NXP, Qorvo and STMicroelectronics have announced Aliro-related silicon or software, which lowers the barrier for lock makers. Third, the three dominant wallet vendors, Apple, Google and Samsung, have publicly committed to the standard, according to the CSA. At the time of the 1.0 announcement, reporting indicated that no shipping product or wallet yet offered Aliro support, so 2026 and 2027 are the rollout window.

Aliro Reference Architecture: Roles, Transports and Layers

In short: Aliro splits an unlock into a user device (phone or wearable) that holds a credential, a reader (the lock or wall unit) that enforces policy, and a protocol that proves the credential is genuine using asymmetric cryptography. Three radio options carry the same protocol: NFC for tap, BLE for longer range, and BLE plus UWB for secure hands-free entry.

Figure 1: Aliro digital key reference architecture. One credential and one access protocol are carried over three interchangeable transports.

Figure 1 reads from top to bottom. The wallet application on the user device holds the credential. The device reaches the reader over one of three transports. Above the transports sits a single access protocol, which performs mutual authentication and exchanges the credential. Below it sits the policy decision, evaluated by the reader without needing a cloud round trip, and finally the actuator that moves the bolt.

The two roles that matter

The specification speaks of a reader and a user device, and independent technical write-ups use the same vocabulary. Readers are door locks and wall-mounted units. User devices are phones and wearables. The reader is the policy enforcement point: it holds the keys and certificates that identify it, and it decides whether to open. The user device is the credential holder: it holds a private key that never leaves the secure environment of the device, and it signs challenges with it.

This division is important for an architect because it fixes where trust lives. A lock does not trust a phone because the phone is on a network. It trusts a signature chain. That is the property that lets a lock in an underground car park or an elevator work with no connectivity, a use case the CSA calls out explicitly.

Three transports, one protocol

The release names three ways to present a key. Near Field Communication (NFC) provides tap-to-access. BLE provides user-initiated access at longer range. BLE combined with UWB provides hands-free authentication. Independent analysis of the specification adds an important detail: NFC is mandatory in every Aliro 1.0 deployment, while BLE and BLE plus UWB are optional. UWB, in other words, is a premium option layered on top of a baseline that always includes tap.

That ordering is a deliberate engineering choice. NFC works with a passive or very low-power reader, needs no pairing, and has a physical range of a few centimetres that doubles as an intent signal. BLE reaches several metres but cannot tell the lock how far away the phone really is. UWB measures distance with centimetre-class precision, which is what allows a lock to open as you reach the door and not while you are still in the car. We cover the physics in our post on UWB real-time location systems, IEEE 802.15.4z and BLE Channel Sounding.

Why asymmetric cryptography is the foundation

Both the press release and independent summaries stress that Aliro secures interactions between user devices and readers with asymmetric cryptography. The design question is why. Older access systems share a secret between card and reader, often through a master key that every reader holds. Compromise one reader and the whole building is at risk. With asymmetric keys, a reader holds only the public keys and certificates it needs to verify credentials, and each credential signs with its own private key. Stealing a reader does not let an attacker mint new keys.

A reverse-engineering effort published on GitHub by the researcher known as kormax, based on observing real wallets and readers, reports the concrete primitives: ECDSA with SHA-256 for signatures, ephemeral ECDH for key agreement, HKDF with SHA-256 for deriving session keys, and AES-GCM for the secure channel. This is third-party analysis of observed behaviour, not the normative text, so treat the details as indicative and consult the specification itself before building against them. The shape, however, matches what you would expect from a modern authenticated key exchange with forward secrecy.

Identifiers that make multi-reader buildings tractable

The same analysis reports that a reader identifier is 32 bytes: a 16-byte group identifier followed by a 16-byte instance identifier. The group identifies a site or deployment, and the instance identifies the individual reader. This split is what lets a credential be scoped to “every door in building A” without enumerating thousands of readers. It also shows up in the NFC polling frame, where part of the group identifier is advertised so a phone can quickly decide whether a nearby reader is one it should talk to. Again, this comes from third-party reverse engineering and should be verified against the specification.

Inside an Aliro Transaction: Expedited and Step-Up Flows

A transaction has two tiers. The expedited tier is a fast mutual authentication that completes in the time of a tap, so the door opens immediately. The optional step-up tier follows when the reader needs more than proof of key possession, such as an attestation or a revocation certificate. Fast mutual authentication is the default path for everyday entry.

Figure 2: An Aliro digital key transaction. AUTH0 and AUTH1 authenticate both sides; step-up is optional and runs inside the secure session.

The sequence in Figure 2 follows the structure that third-party protocol research and the open-source certification tooling describe. The reader selects the Aliro application on the user device. It then sends a first authentication command, conventionally called AUTH0, which carries the reader’s ephemeral public key, a transaction identifier and flags. The user device replies. The reader sends AUTH1, which includes the reader’s signature. The user device answers with its own signature and, if requested, identity elements. Session keys are derived at the end, and the reader evaluates policy.

Expedited fast versus expedited standard

The reverse-engineering notes describe two modes inside AUTH0. In the standard mode, the exchange continues to AUTH1 and performs a full signature-based authentication. In the fast mode, the user device returns a cryptogram bound to a persistent key from a previous successful session. If the reader and device have met before, that cryptogram lets the reader skip the signature step. If the context is missing, the device returns data that fails verification, and the reader falls back to the standard path.

The engineering logic is straightforward. Elliptic-curve signatures are cheap on modern silicon, but a tap has a budget of a few hundred milliseconds, and a battery-powered lock wants to minimise radio-on time. A previously established symmetric key makes repeat visits faster. The cost is state: both sides must store the persistent key and handle the case where one side has lost it. That is a classic cache-coherence problem, and the fallback path is what makes it safe.

Per the same notes, the persistent key is derived after a successful full authentication using HKDF-SHA256 with a fixed domain label, and reused in later fast attempts. Domain-separation labels keep keys derived for different purposes cryptographically independent, which is good practice: a leak of one derived key does not hand over the others.

The secure channel and derived keys

After authentication, commands travel in an AES-GCM channel. The reverse-engineering analysis reports a 16-byte tag, a 12-byte nonce built from a fixed per-direction prefix plus a counter, and separate keys per direction. Directional keys matter because they prevent a message from one side being replayed to that same side. Counters give replay protection within a session.

The same key schedule produces several outputs, including keys for the exchange phase, for step-up, for a BLE session, and a 32-byte UWB ranging secret key. One independent write-up describes the schedule as HKDF-SHA256 producing 160 bytes split into five 32-byte keys, as implemented in an open-source actuator. This is why the UWB link needs no separate pairing: the ranging secret falls out of the same authenticated handshake that proves the credential.

Step-up: attestation and revocation without bloating the tap

Step-up is the optional second tier. Research notes report a separate application identifier for the step-up applet and note that step-up keys exist only after AUTH1 has completed. The reader uses it to request items such as attestation or revocation certificates. In high-assurance environments, such as a data centre, a reader might require proof about the device itself, not only the key. In a home, the reader would never ask.

The architectural value is that the common path stays small. Most unlocks never need extra data, so they never pay for it. When a reader does need more, the secure channel is already up. Compare this with legacy card systems, where adding a new check often meant reissuing every card.

Worked timing example (illustrative)

Suppose a tap budget of 300 ms. These numbers are illustrative, not measured: NFC field activation and application selection might take tens of milliseconds, the AUTH0 and AUTH1 exchange a few round trips of short messages, and the policy check microseconds. The dominant term is usually radio round trips, not cryptography. That is why fast mode, which removes a round trip and a signature verification, is worth the state it costs. If you benchmark a real reader, measure from field detect to actuator command, not just cryptographic time.

BLE and UWB: From Tap to Hands-Free Entry

For hands-free entry, Aliro uses BLE to discover the reader and run the same authentication, then UWB to measure distance. The reader unlocks only when the measured distance falls inside a configured zone. Because the ranging key comes from the authenticated session, only a device that passed authentication can produce valid ranging frames.

Figure 3: Hands-free entry with BLE plus UWB. BLE carries authentication and UWB setup; UWB ranging rounds decide whether the user is close enough.

Independent technical coverage describes the flow in Figure 3. The reader advertises, the user device connects over BLE and opens an L2CAP channel (a BLE data channel), and the two run AUTH0, AUTH1 and the credential exchange. From the key schedule they derive a BLE session key and the UWB ranging secret key (URSK). The BLE key encrypts the UWB setup messages with AES-GCM. Four setup messages, labelled M1 to M4, agree the ranging parameters: configuration, channel (5 or 9 is reported), preamble code, slot and round sizes, hopping, MAC mode and session start time.

Why the relay attack is the whole point

Passive keyless entry on cars was long defeated by relay attacks: an attacker amplifies the signal between a key fob and a car so the car believes the fob is nearby. BLE signal strength cannot defend against this, because signal strength is not distance. UWB can, because it measures time of flight.

The scrambled timestamp sequence (STS) in IEEE 802.15.4z is the mechanism. The ranging frame carries a cryptographically generated sequence seeded from a shared secret, here the URSK. The analysis notes that a relay can only add delay, which shows up as a longer distance, and that a device without the key cannot produce ranging frames that pass the STS check. An attacker can make the phone look farther away. They cannot make it look closer. For deeper background on STS and ranging, our UWB RTLS and 802.15.4z walk-through covers the physical layer.

Suspend, resume and reader status

Hands-free sessions are long-lived compared with a tap. The notes report suspend and resume messages that let the two sides pause ranging and restart it inside the same session, and a status message the reader sends to the user device when its state changes. This matters for battery: ranging continuously drains both the phone and the lock. A design that parks ranging when the user is far away and resumes it on approach is not a nicety but a requirement for a coin-cell or AA-powered lock.

Where BLE alone fits

BLE without UWB remains useful. The release describes it as user-initiated, longer-range access. Think of a gate or garage barrier where the user presses a button on the phone from the car, or a lock in a place where UWB is not deployed. The reader gets a valid credential signature but no secure distance measurement, so policy should treat it as a weaker proximity assurance than UWB. Independent analysis calls BLE plus UWB the only secured hands-free mode, which is a polite way of saying hands-free over BLE alone would be unsafe.

Comparison to Bluetooth Channel Sounding and BLE mesh

Bluetooth 6.0 introduced Channel Sounding, a phase-based ranging feature for BLE that targets secure distance measurement. Whether future Aliro revisions adopt it is not stated in the sources I verified, so I make no claim either way. It is worth watching because it could lower the hardware cost of secure ranging. Aliro also should not be confused with Bluetooth mesh, which is a many-to-many network for lighting and sensors. Aliro is point to point: one user device, one reader, one session.

Credentials, Access Documents and Offline Policy

The credential in Aliro is not a password stored in a wallet. It is a key pair plus a digitally signed Access Document issued by a trusted authority. The reader verifies the signature and evaluates rights such as schedules without contacting a server, which is what makes offline operation possible.

Figure 4: Credential issuance and offline verification. The issuer signs rights once; the reader checks the signature and policy locally.

Industry coverage of the release describes the Access Document as the mechanism that lets an offline lock verify access. The document can include schedules, so a key works only on certain weekdays and hours. The example given is a dog walker who may enter on weekday afternoons. Credentials can also limit actions, for example permitting a temporary unlock while blocking changes to the lock’s permanent security state. The sources do not detail the sharing workflow, and sharing between wallets is a roadmap item, so the exact encoding is something to read in the specification rather than infer here.

Provisioning is two-sided

Figure 4 shows two provisioning paths feeding the reader. The issuer, which might be a landlord platform, a corporate identity system or a lock vendor’s cloud, signs documents for user credentials. Separately, the reader must be provisioned with the keys and certificates that identify it and let it verify issuers. Third-party research notes that readers load compressed certificates and that detailed certificate chain rules are deferred to other parts of the specification. Practically, the work of a lock manufacturer or integrator is to build a provisioning and lifecycle process around these two paths.

Revocation is the hard problem of offline systems

Offline verification trades freshness for availability. If a reader never talks to a server, how does it learn that a key was revoked? The sources point to two tools. Short validity windows in the Access Document limit exposure: a key that expires tomorrow cannot be abused next month. And the step-up tier can request revocation certificates, as the protocol research reports, when a reader has a way to obtain them.

A sensible design combines both. Issue short-lived documents for high-risk doors, refresh them in the background while the phone has connectivity, and let readers with a network link push revocation lists. For a home lock, expiry plus an owner’s ability to remove a user locally is usually enough. For a hospital pharmacy, you want attestation and tight windows.

What lives in the wallet and what does not

Apple, Google and Samsung wallets host the credential on the user’s device, using the platform’s secure element or equivalent hardware protection. Because the wallet vendor provides the secure storage and the biometric or passcode gating, a lock maker does not need to build a phone app to get a good user experience. That is the commercial heart of the standard. A lock maker still may offer an app for administration, logs and guest invitations, but the unlock path itself runs through the wallet.

One consequence is that features visible in the wallet user interface, such as Express Mode that works without authenticating each time, are decided by the wallet vendors, not by Aliro. The reverse-engineering notes report observed express-mode identifiers for Aliro and for Apple Home Key, which hints at how wallets treat the two. Do not assume that every wallet exposes the same options.

Aliro, Matter and Apple Home Key: How They Relate

Aliro and Matter are separate CSA projects. A lock does not have to be a Matter device to support Aliro, and a Matter lock does not have to support Aliro. Some products will carry both. Matter handles network commissioning and control through home ecosystems. Aliro handles the person-to-lock credential exchange.

An analysis from Matter Alpha states exactly this: the two are parallel projects, locks may carry both badges, and Aliro is not open source for now. Note that this last point refers to the specification’s licensing and community model; the CSA separately publishes an open-source Aliro certification tool, as independent coverage reports, under the Apache-2.0 license.

This split has architectural consequences worth spelling out:

Admin versus access. Matter lets a hub lock or unlock a door remotely, read its state and manage users through the Door Lock cluster. Aliro lets a wallet open it locally. A lock supporting both gives you remote administration plus offline tap-and-go.
Failure independence. If your Wi-Fi or Thread network fails, a lock with Aliro still opens for a tap. If the wallet vendor changes something, Matter control continues.
Commissioning. NFC commissioning in recent Matter releases, covered in our Matter 1.6.1 developer guide, is about joining a device to a fabric, not about presenting a user credential.

Relationship to Apple Home Key

Press coverage describes Aliro as an open counterpart to Apple Home Key that adds broader device and wallet support. Home Key worked only for Apple users and required lock makers to work directly with Apple. The same coverage notes that Apple must officially add Aliro support before an Aliro-only lock appears in Apple Home, and that at the 1.0 announcement none of the three wallet vendors had confirmed shipping dates. The reverse-engineering notes report that Apple, Google and Samsung wallets already speak Aliro protocol versions 1.0 and 0.9 in observed behaviour, which suggests development is further along than public timelines. Treat that as a hint, not a commitment.

Certification and who is first

The CSA runs a certification program with test suites delivered through Authorized Test Labs. The announcement lists companies expected to be first to certify: Apple, Allegion, Aqara, Google, HID, Kastle, Kwikset, Last Lock, Nordic Semiconductor, Nuki Home Solutions, NXP Semiconductors, Qorvo, Samsung Electronics and STMicroelectronics. An open-source Aliro Certification Tool runs NFC and BLE suites, including cases that start UWB ranging, according to independent coverage. For a product team, that tool is a cheap way to find protocol bugs before paying for lab time.

Product examples named in press coverage include the Aqara U400, Kwikset Halo Select Plus, Nuki Keypad 2 NFC, Ultraloq Latch 7 Pro and the Schlage Sense Pro, with Aliro support described as planned or pending updates at the time of reporting. Check each vendor’s current certification listing on the CSA site before buying, because planned is not certified.

Silicon and software

Chipset vendors have published Aliro-oriented support. Nordic provides an Aliro-related door lock add-on for its nRF Connect SDK, STMicroelectronics has an Aliro software expansion for STM32Cube, Espressif has an Aliro repository on GitHub, and Qorvo supplies an SDK for its UWB parts. One detail from Nordic’s documentation, as reported, is that a third-party UWB SDK must accept an externally supplied URSK. That is the integration seam: the host microcontroller runs the authentication and hands the ranging key to the UWB chip.

How Aliro Compares With Proprietary and Legacy Access Control

Dimension	Legacy 13.56 MHz cards	Vendor BLE app	Apple Home Key	Aliro 1.0
Credential holder	Plastic card	Vendor app	Apple Wallet	Apple, Google, Samsung wallets (committed)
Offline unlock	Yes	Usually yes	Yes	Yes by design
Cross-vendor locks	Within a card family	No	Apple-approved locks	Any certified reader
Hands-free	No	Weak, RSSI-based	Limited	BLE plus UWB option
Cryptographic basis	Varies, often shared keys	Vendor-specific	Asymmetric	Asymmetric
Governance	Vendor consortia	None	Apple	CSA with certification

The table is a conceptual summary based on the sources above, not a feature audit of specific products. Its main message is that Aliro’s novelty is not any single technology. Wallets, NFC, BLE and UWB already existed. The novelty is that the combination is specified publicly and certified independently, which turns a negotiation between two companies into a conformance test.

An original angle for architects: think of Aliro as a credential protocol in the same family as FIDO and WebAuthn, only for doors. It binds a user-held private key to a relying party, uses challenge-response, and avoids shared secrets. Seen that way, the design questions you already know apply: attestation, key backup, account recovery, and what happens when a phone is lost. Aliro leaves the last two largely to wallets and issuers.

Trade-offs, Gotchas, and What Goes Wrong

The first gotcha is the gap between standard and ecosystem. A specification can be complete while wallets lag. Apple, Google and Samsung have committed, but no one can promise a date, and a lock that works only through a wallet feature that has not shipped is a brick with a nice finish. Buy locks that retain a working fallback such as a PIN pad or mechanical key.

Second, UWB is optional. A marketing claim of “Aliro support” does not imply hands-free. Ask which transports a product has certified. NFC is always there; BLE and UWB are options.

Third, offline revocation is genuinely hard. A phone stolen from a user with a still-valid Access Document may open a door until the document expires or the reader learns of the revocation. Wallet-level biometric or passcode gating helps but is not a substitute for short validity windows.

Fourth, battery and range. Continuous UWB ranging on a battery-powered lock is expensive, and the suspend and resume design exists for that reason. Expect vendors to tune ranging aggressively, and expect some real-world variability in how early a lock opens. Metal doors, body shadowing and antenna placement all affect UWB in ways a spec cannot remove.

Fifth, privacy. Identifiers that let a reader recognise a returning device are useful for fast mode and dangerous for tracking. The CSA states that the specification respects user privacy, but I could not verify the normative mechanisms from the sources I read. If you are building a product, audit how persistent identifiers are exposed over BLE advertising and NFC polling.

Finally, a caution on third-party protocol research. Reverse-engineering projects are valuable, but they describe what particular wallets and readers did on a particular day. Details such as tag numbers, labels and versions can change between wallet releases or differ from the normative text. Use them to understand the design, not as a replacement for the specification.

Practical Recommendations

If you are a lock manufacturer, start with the CSA specification and the open-source certification tool, choose a chipset vendor with a maintained Aliro stack, and decide your transport matrix early: NFC only is the cheapest, adding BLE is moderate, and adding UWB changes your bill of materials, antenna design and battery budget. Plan certification time and lab cost into the schedule.

If you are a property manager or integrator, ask vendors three questions: which transports are certified, which wallets have been tested end to end, and how revocation works when a reader is offline. Insist on a local override for the case where a phone battery dies.

If you are a homeowner, treat Aliro support as a promising feature and not as a purchase reason on its own. Prefer a lock with NFC today and a roadmap, keep a physical or keypad fallback, and wait for your phone’s wallet to confirm support before relying on it.

A short checklist:

Confirm certification status on the CSA site, not on the box.
Verify which of NFC, BLE and UWB the product actually implements.
Test cold-start behaviour: first unlock after a reboot, with no persistent context.
Define expiry for every shared credential.
Keep a non-digital fallback for every door.
Log unlock events locally and review them.

Frequently Asked Questions

What is the Aliro digital key standard?

Aliro is a communication protocol and credential standard published by the Connectivity Standards Alliance. Version 1.0 was announced on 26 February 2026. It lets digital keys stored in phone and wearable wallets open locks and readers from different manufacturers over NFC, Bluetooth LE or Bluetooth LE plus UWB. It uses asymmetric cryptography and is designed to work without a network connection, for example in garages and elevators.

Is Aliro the same as Matter?

No. Both come from the Connectivity Standards Alliance, but they are separate projects. Matter connects smart home devices to networks and ecosystems for control and automation. Aliro authenticates a person’s credential to an access reader. A lock can support Aliro without Matter, Matter without Aliro, or both. Supporting both gives remote administration plus offline wallet-based entry.

Does Aliro require UWB?

No. According to independent analysis of the specification, NFC is mandatory in every Aliro 1.0 deployment, while Bluetooth LE and Bluetooth LE plus UWB are optional. UWB is what enables secure hands-free entry because it measures distance using time of flight. A lock without UWB can still support tap and user-initiated Bluetooth access, so check which transports a specific product certifies.

Which phones and wallets support Aliro?

Apple, Google and Samsung have committed to supporting Aliro in their wallets, according to the CSA. At the time of the 1.0 announcement, press coverage said no ecosystem had yet shipped support, and none had given firm timelines. Check your phone vendor’s current release notes and the lock’s compatibility list before assuming a particular combination works today.

Not as a defined feature of version 1.0. The CSA lists secure key sharing as a planned later phase of a living standard. Credentials can carry schedules and limited rights through signed Access Documents, and issuers such as property platforms may provide their own guest workflows. Until the standard defines sharing, availability depends on the lock vendor and the wallet.

Is Aliro secure against relay attacks?

For hands-free entry, the design is built to resist them. The UWB ranging key is derived from the authenticated session, and the scrambled timestamp sequence means a relay can only add delay and make the device look farther away. Tap-based entry has inherent physical proximity. Bluetooth alone gives no secure distance measurement, so it should be treated as weaker proximity assurance.