On June 10, 2026, Safetrust hosted the webinar “Aliro Decoded: What Enterprise Security and Identity Leaders Need to Know Before 2027,” and the audience came ready with questions. Attendees wanted to know how Aliro stacks up against PKOC and LEAF, what it really costs to put credentials in Apple, Google, and Samsung wallets, who manages the certificates behind the standard, and whether their existing PACS needs to change at all. Others dug into the harder edge cases: shared readers and TCIs, post-quantum readiness, reader output formats, and where Aliro fits (and doesn’t) in federal environments.

We received far more questions than we could answer live, so we’ve gathered the most frequently asked ones here, along with our answers. If you missed the webinar or want a deeper look at any of these topics, reach out to the Safetrust team.

Q1: At ISC West, Wavelynx was promoting Aliro, tied with LEAF Verified to handle both mobile and physical credentials. Why do I need to have two separate credential systems?

You definitely don’t, LEAF Verified and Aliro are competitive. LEAF Verified is an NXP DUOX chip-only card implementation, while Aliro is a multi-form-factor mobile, card, wireless, keyfob, etc., so pairing it with Aliro means running two parallel credential systems: one for cards, one for mobile, each with its own keys, issuance, and management. Aliro alone covers both. It uses a single protocol for cards and mobile devices, with the credential controlled by the end user. One system means lower deployment and management costs, a single security model to audit, and no duplicate credential lifecycle. Aliro can run alongside legacy systems during migration and then fully replace them, with no need for LEAF or any other card protocol. Aliro has the benefit of built-in privacy and mutual authentication; LEAF Verified has neither and is a free-read certificate implementation.

Q2: We’ve heard this from PKOC, LEAF, etc., about how “open” or “interoperable” it will be, but it hasn’t gained any traction… How will this be different?

The difference is who is driving it. PKOC and LEAF are initiatives within the access control industry, and neither controls the phones on which mobile credentials depend. Aliro is a Connectivity Standards Alliance specification developed with Apple, Google, and Samsung, the companies that control the mobile wallets and operating systems. That means Aliro credentials work natively in the phone’s wallet, with no app required. With more than 400 member organizations behind the standard, readers, locks, and credentials from different vendors interoperate by design, which drives down prices and expands options rather than locking buyers into one supplier’s ecosystem.

Q3: How is the mailbox to send a tamper message different than the reader communicating to the controller/cloud via OSDP or Wi-Fi?

OSDP and Wi-Fi require the reader to have its own connection to the controller or cloud. The mailbox does not. It uses the mobile wallet as the transport, so each phone that presents a credential also carries messages between the lock and the host. That gives offline door locks a way to report tampering and receive updates without any wiring or network hardware, and it lets legacy Wiegand-connected readers receive configuration updates they lack a return channel for today. For a reader that already has panel connectivity, the mailbox adds less, but it is another tool with many potential use cases.

Q4: How well does this play with Apple? We know they are notorious for getting their cut of money when it comes to credentials, and especially “certifying” with them. How many hidden costs will there be with these wallets that these credentials will need to be stacked on?

Very well, and with fewer hidden costs than today. Most of the cost and friction of getting a credential into Apple Wallet comes from the proprietary work: defining application IDs and file structures, maintaining a custom profile with each handset vendor, and certifying that proprietary implementation, as with DESFire on Apple Wallet. Aliro eliminates that layer. The standard defines the certificate and data model, so issuers implement a single specification that works across Apple, Google, and Samsung wallets instead of negotiating and maintaining separate configurations with each. The wallet platforms’ own terms still apply, but they are the same published terms for every Aliro issuer, so there is no per-vendor negotiation where hidden costs usually live.

Q5: How will Aliro compare to other interoperable solutions like PKOC?

Both are open credential standards, but Aliro covers more ground. The biggest difference is mobile and security: Aliro credentials live natively in Apple, Google, and Samsung wallets, while PKOC has no wallet support today. Aliro also standardizes the full communication between the credential and the reader for both cards and phones, so a single protocol serves the entire deployment. Aliro offers full mutual authentication and privacy, while PKOC is a free-read credential with neither. For organizations already using PKOC, the transition is low-risk because both can run on the same card, allowing Aliro to replace PKOC at whatever pace makes sense.

Q6: If Aliro credentials are placed in Apple Wallet, does this follow the logic of each end customer, or does each wallet launch have a unique TCI value?

TCIs follow the end customer. Apple still expects each credential to include a TCI that matches the building or organization where it will be used. The TCI, in simple terms, is broadcast by the reader to Apple Wallet, allowing it to display the correct pass for the building or reader.   TCIs complicate multi-organization shared readers because a reader can have only one TCI at a time.  To address this, careful consideration is required in multi-use environments, such as each issuer adding multiple TCIs to their Aliro pass.  There are things in the works to make this easier in the future, but it is one of the current complications of a shared environment with Apple Wallet. Aliro adds a positive twist: because it natively supports BLE/UWB, it’s possible to overcome the NFC TCI issue by leveraging them.

Q7: What costs will be associated with this from the vendor/manufacturer side down to the end user?

Because Aliro is an open standard, there are no proprietary protocol licensing fees baked into every credential and reader, which is a structural cost advantage over closed ecosystems. The main ongoing cost is certificate management: for Aliro Enterprise, the public certificates on readers and credentials are managed as a service, and there may be small subscription fees to support that. Vendors avoid the cost of building and maintaining separate integrations for cards, mobile, and each wallet platform, and those savings flow down to integrators and end users through more competition among interoperable products.

Q8: Is Aliro post-quantum ready?

Not yet, but it is built to get there cleanly. While Aliro uses the state-of-the-art crypto today, Aliro is a software-defined standard, not tied to any specific chip or hardware, so when the Aliro working group updates the specification with post-quantum algorithms, the changes roll out as software updates. The practical question is whether your readers can receive them. Safetrust readers are connected devices with leading-edge processors and update over the air. Most legacy readers in the industry will need a technician at each door to update them, if their hardware can support the new algorithms at all. Choosing OTA-updatable hardware now is the real post-quantum preparation.

Q9: Integrated with 30+ PACS? What does the PACS need to do, if anything, to play along?

Conveniently, the PACS doesn’t need to do anything. The point about integration is that credentials can be issued into many different head ends and kept up to date. The access document in Aliro stores a standard card number and facility code if your PACS expects that.

Q10: Since the underlying architecture for Aliro is digital certificates, do I need to have a certificate authority in my environment?

No. You do not need to stand up or operate any PKI infrastructure yourself. You have several choices: you can rely on your credential and reader suppliers to issue and manage the certificates for you, which is the simplest path, or, if your organization wants full control of trust, you can sign your own root certificate or use a publicly signed root. Either way, certificate handling happens behind the scenes and adds no day-to-day administrative burden for credential issuers or for readers.  Depending on your cyber policy, you may be required to refresh your trusted certificates periodically.  Both Aliro Mailbox and Safetrust Connected devices can deliver those updates when the time is right and provide management to ensure the system is running as expected.

Q11: Aliro does not mandate how the data is output from the reader (to my understanding), whereas PKOC does, using the truncated key pair. Do you think that, as a future revision of the Aliro spec, output data should be defined to help us move away from traditional PACS formats?

Output is generally determined by the Aliro credential. Unlike in the old world, the credential issuer defines a field called PACS_ID, which readers are recommended to use.  However, it isn’t prescriptive, and in the Safetrust world, you can configure your sensors to transform the data into various traditional formats, such as H10103.  

But you are not locked in; you can define your own structure. Yes, there is a lot of flexibility, and it is needed to support the 40-year legacy of proprietary systems. 

Some vendors have taken a similar approach to PKOC, with the X component of the credential being output. The X component can also be used and truncated or hashed in a similar way to PKOC, but this really isn’t necessary in the Aliro world because the precise format you need can be configured on each card, and the card can define how that is output. 

Q12: It seems that setting up Aliro may be complex to set up and maintain the certificates. What can security managers do to keep it fairly simple to set up and maintain?

The certificate architecture does not have to mean certificate work for your team. The simplest step is to choose credential and reader suppliers who handle certificate management for you, issuing, distributing, and renewing certificates as part of their service. Done that way, certificates operate behind the scenes like any other managed infrastructure, and the day-to-day experience is no more complex than managing credentials today. When evaluating suppliers, ask specifically how certificates are issued and renewed, whether updates are delivered to readers over the air, and what happens upon certificate expiry. The answers will tell you quickly whether the complexity lies with the supplier or with you.

Q13: For Federal and CIV use cases, how does Aliro plan to handle strict hardware-bound credential requirements on traditional card form factors?

It doesn’t, by design. Aliro is not intended to replace PIV, CIV, or other federally mandated credential programs, which carry hardware binding, issuance, and certification requirements defined by FIPS 201 and related policy. Those use cases will continue to run on their existing credential infrastructure. Where Aliro fits in a federal environment is alongside those programs, for example, covering visitor access, non-regulated facilities, or commercial tenants, while regulated doors stay on the mandated credential. Multi-technology readers can support both on the same hardware. While Aliro technically runs on the same silicon card types as PIV, it is not currently GSA-approved.

Q14: Who would be the CA for the enterprise market, or any recommendations?

Expect several options rather than a single industry CA. Credential and reader suppliers will offer CA services as part of their platforms, and we’re biased, but we’d recommend Safetrust, where certificate management is built into the service. We also expect some IAM providers to act as CAs for the credentials they issue, which makes sense where the IAM is already the source of identity truth. And as noted earlier, organizations that want full control can self-sign their own root. The practical recommendation: pick the CA that aligns with whoever already manages your credential lifecycle, so that certificates remain someone else’s job rather than becoming a new one for your team.

Still have questions?

Have a question we didn’t cover? Contact us at sales@safetrust.com and we’ll be happy to walk through how Aliro fits your environment.